SPF record generator

Tick every service that sends email as your domain, add your own servers if you have any, and choose what receivers should do with mail from anywhere else. The record updates as you go, with the number of DNS lookups it costs and anything that would break it.

SPF (Sender Policy Framework, RFC 7208) lets a receiving server ask your domain: is this server allowed to send mail for you? The answer lives in a TXT record at the domain itself. The receiver checks the domain in the envelope sender (the Return-Path, where bounces go), not the From address people see.

That detail matters. SPF on its own does not stop someone from putting your address in the From line. DMARC closes that gap by requiring SPF or DKIM to pass for a domain that matches the From address. If you are new to the three, read SPF, DKIM and DMARC explained first.

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

Checking an SPF record may cause at most 10 DNS lookups for include, a, mx, ptr, exists and redirect (RFC 7208 §4.6.4). Addresses cost nothing. Each include costs one, plus every include nested inside the provider’s own record. Go over and the receiver returns permerror: SPF fails for all your mail, not just the last service you added.

The generator counts the nested lookups of the providers it knows, as their records stood when this page was checked. For any other include it counts one and tells you the total may be higher. Providers change their records without notice, so check the final count with a DNS lookup tool now and then.

When you run out of lookups

• Move bulk or marketing mail to a subdomain (news.example.com). Each subdomain has its own record and its own budget of 10.
• Drop includes for services that authenticate on their own bounce domain (see below).
• Replace an include with the provider’s published ip4 and ip6 ranges, only if they document stable ones. You then have to watch them for changes.
• Remove services you no longer use. Old includes are the most common cause.

SPF checks the Return-Path domain. Many sending services use their own Return-Path, or one on a subdomain of yours that they manage, so adding them to your root record spends a lookup for nothing.

1. 1Look for an existing TXT record at your domain (host @) that starts with v=spf1.
2. 2If there is one, edit it and replace its value with the generated record. Never add a second SPF record: two records make SPF fail with permerror.
3. 3If the record is longer than 255 characters, paste the quoted, split form if your DNS panel asks for it. Receivers join the strings back together.
4. 4Wait for the TTL to pass, then send a message to a Gmail account and check "Show original": SPF should say PASS.
5. 5Publish a DMARC record with reports, so you can see every server that sends as you before tightening anything.

Not sure which records your domain needs in total? The MX records guide and the deliverability checklist list them all.

• Two SPF records on the same domain, one per provider. Merge them into one.
• Using ptr. It is deprecated, slow, and receivers may ignore it (RFC 7208 §5.5).
• Ending with +all or ?all, which authorizes anyone or says nothing.
• A trailing dot or a space after include: (include: _spf.google.com). Both break the record.
• Forgetting a sender: the billing tool, the helpdesk or the website’s contact form. DMARC reports show them.
• Adding mx out of habit. It only belongs there if your incoming servers also send.

If you host mail with Skein, the app writes these records for you on supported DNS providers. The demo shows the rest of the product with sample data.