SPF, DKIM and DMARC for the 2026 Gmail and Outlook rules

Gmail's sender guidelines, the Gmail sender FAQ, Outlook.com's postmaster announcements, and Yahoo's Sender Hub specify the same three TXT records once a domain is sending in volume. Gmail's guidelines put the bulk line at more than 5,000 messages a day to personal Gmail accounts. The FAQ says a domain that reaches it once stays there, and mail from subdomains counts toward the same primary domain. Outlook.com's support article for the bounce uses 5,000 or more messages to its consumer mail, counted on the domain in the From header. Yahoo's FAQ still declines to publish a number.

example.com carries the records. The SPF addresses, 203.0.113.10 and 2001:db8::10, are the documentation ranges in RFC 5737. They were served on this machine and read back with dig. A count of lookup terms in that SPF line returned 0, under the limit of 10 in RFC 7208 section 4.6.4. The DKIM public key is 2048 bits. Gmail's minimum for personal Gmail accounts is 1024, and Yahoo's minimum is 1024. The check on this machine was the records, the key, and the SMTP banners. An Authentication-Results line needs a message, and none was sent.

What Gmail and Outlook require in 2026

Gmail's rules for every sender have been in force since 1 February 2024: SPF or DKIM, a PTR that matches a forward lookup, TLS, a spam rate in Postmaster Tools under 0.3%, and a message shaped like RFC 5322. Impersonating a Gmail address in From is called out on its own. Gmail is moving that case onto a DMARC quarantine policy.

Above 5,000 messages a day, SPF and DKIM both have to be published, and a DMARC record has to exist. p=none meets that floor. For mail you send directly, the domain in From has to align with the SPF domain or the DKIM domain. The FAQ exempts forwarded mail and mailing lists from that alignment rule. Marketing mail needs one-click unsubscribe, honored within 48 hours. Bulk senders are told to keep the user-reported spam rate under 0.1%. Since June 2024, a rate above 0.3% removes eligibility for mitigation until it has stayed under 0.3% for seven days running.

The FAQ's note for November 2025 says Gmail is ramping temporary failures and permanent rejections where traffic misses those requirements. Unauthenticated mail can be rejected with a 5.7.26 error. The permanent codes under that are 5.7.27 for SPF, 5.7.30 for DKIM, and 5.7.25 when the PTR is missing or the forward lookup disagrees. 4.7.27 and 4.7.30 are the rate-limit versions of the SPF and DKIM failures. A missing DMARC record is listed apart from those codes: delivery support and mitigations are unavailable.

Outlook.com's announcements page says enforcement for domains sending over 5,000 messages a day began on 5 May 2025. Non-compliant mail goes to junk, and the page says rejection follows if the DNS stays wrong. Microsoft's article for the bounce gives the text.

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.

That article defines a high-volume sender as 5,000 or more messages to Microsoft's consumer services, Hotmail, Live, and MSN among them, all using the same domain in the From header. Both SPF and DKIM have to pass. A DMARC record has to be published. The example they print is v=DMARC1; p=none. At least one of SPF or DKIM has to align with that From domain.

Yahoo counts the complaint rate under 0.3% on mail that reached the inbox. A mailto unsubscribe still satisfies their list-unsubscribe line, and they recommend the RFC 8058 POST method on top of that. The Sender Hub FAQ publishes no volume threshold. The DKIM floor is 1024 bits, and an unsubscribe is to be honored within two days.

A PTR still has to match. This guest opened port 25 to gmail-smtp-in.l.google.com and received 220 mx.google.com ESMTP. The same check to outlook-com.olc.protection.outlook.com received 220 and Microsoft ESMTP MAIL Service ready. Both connections were closed with QUIT. The address this guest uses to leave the network has no PTR. 1.1.1.1 and 8.8.8.8 both answered NXDOMAIN. Gmail's permanent code for that is 5.7.25.

SPF and the 10 lookup limit

SPF is a TXT record on the domain of the envelope, the MAIL FROM address. It names who may send for that domain. A VPS that sends as itself can publish the addresses and stop.

v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all

Put the VPS's own public addresses in place of the documentation ranges. ip4 and ip6 skip DNS at evaluation time. include, a, mx, ptr, exists, and redirect each cost a lookup. Section 4.6.4 limits the whole evaluation to 10 of those terms. Cross it and the result is permerror. The record is invalid, so the sending address is never compared with the list.

-all fails everyone else. ~all soft-fails everyone else, which is the qualifier to leave in place while a domain still has senders you have not found. A domain that sends only from this VPS can publish -all. A provider, a web form, or a support desk that also sends as the domain has to be named in the record first. Otherwise that mail fails SPF.

One name gets one SPF record. Section 4.5 says that if the lookup returns more than one record beginning with v=spf1, the result is permerror. A second TXT on the same name that also starts with v=spf1 is the usual cause. Other TXT records on the apex, a site-verification string for example, are ignored during SPF evaluation unless they begin with v=spf1.

import sys
LIMIT = {"include", "a", "mx", "ptr", "exists", "redirect"}
n = 0
for term in sys.argv[1].split()[1:]:
    name = term.lstrip("+-~?").split(":", 1)[0].split("=", 1)[0].lower()
    if name in LIMIT:
        n += 1
print(n)

On the VPS line the script printed 0. The other line is one record, include:_spf1.example.com through include:_spf11.example.com, then -all. That is eleven include: terms, and the script printed 11. Each include: tells the receiver to fetch the SPF record at that name. Eleven of them is already over the limit of 10, before any of those names is resolved. Those eleven names are placeholders for the count. An include that points at a record full of further includes spends those lookups too. This script counts only the terms in the record you pass it. When you add a mail provider, ask how many lookups their include uses, and add that number to yours.

A 2048-bit DKIM key

DKIM signs the message. The receiver fetches the public key from s1._domainkey and checks the signature against it. The private key stays on the machine that signs. DNS gets the public half.

Gmail requires 1024 bits or longer for mail to personal Gmail accounts, and recommends 2048 where the DNS host can store it. Yahoo's floor is 1024. The key for this readback is 2048 bits. The SubjectPublicKeyInfo, base64-encoded, is 392 characters. With v=DKIM1; k=rsa; p= in front, the TXT value is 410 characters.

A DNS character-string holds 255 octets. This value was split into 255 and 155. dig prints the two pieces as separate quotes. The receiver concatenates them, so the break can land in the middle of the base64.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out dkim.pem
openssl pkey -in dkim.pem -pubout -outform DER -out dkim.pub.der
openssl pkey -pubin -inform DER -in dkim.pub.der -text -noout | head -1
openssl base64 -A -in dkim.pub.der | wc -c

Generate your own key. The p= value in the next block is the public half of a keypair made for this readback. The private half was discarded, so publishing this same p= on a live domain makes every DKIM check fail.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxROJMq9Irfv96MdawcGM4wkIs3fBe6xeNMJBkH2oi8PE6fqvlHcNoTBZBchIkaT1/6wGdTvdOZGQz76YNvzh7K9KKc0a4SJBlXEjZAQvNHnvs99+DG/ro+v8eEYGiijN/dftEJUFu5hKkPFl4J7BScM6N7LxfgFKTTf15347ILiEBl9s0DEgg52R4u+AbgxtbeeDADLIB+2s3XkYxFgmmEowxCK37wqoMYR7NphZLxoC99c2shm0DmlAsLuzhpW2IB9haPanAGQ7oAnaTv/jmZ9ONHnlcRb/KbhAMjwRG9UAvdFELR6JZPkz8OhWWM07yPxzNJsmLjTZxtD/SBLamQIDAQAB

The first character-string ends at Abgxtb. The second begins at eeDAD. To rotate, publish s2, start signing with it, wait out the TTL, and then remove s1. The selector in the signature and the name in DNS have to be the same one.

DMARC at p=none

DMARC is the TXT at _dmarc. It tells a receiver what to do when both SPF and DKIM fail to align with the domain in From.

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

p=none asks the receiver to take no specific action on a failure. RFC 7489 defines it that way, and it is the floor Gmail, Outlook, and Yahoo each accept. adkim=r and aspf=r are relaxed alignment. Both tags default to r if you leave them off. Relaxed means a subdomain counts as the organizational domain, so [email protected] can align with a signature for d=example.com. Strict, s, requires the same host name.

rua is where the aggregate reports go. They arrive as XML, usually once a day, one file per reporter. A row names a source IP, a count, the SPF result, the DKIM result, and what the receiver did with the message. An unfamiliar source IP is either someone forging the domain or a sender you forgot, and the file looks the same either way. Read a week of them before you change p=.

quarantine is the next step. pct is the share of failing mail the policy applies to, from 0 to 100, and the default is 100. pct=25 applies quarantine to a quarter of the failures and leaves the rest on the previous behavior. After the reports match the senders you expect, p=reject asks receivers to refuse failures during the SMTP conversation.

p=reject is where lists and forwarders get hurt. A list that rewrites the subject or adds a footer breaks the DKIM signature. The list sends from its own IP, outside your SPF record, so SPF fails as well. The message then fails DMARC, and a receiver that honors p=reject refuses it. Yahoo tells forwarders to add ARC, the chain an intermediary uses to record the authentication result it saw. A SaaS product that sends with your address in From has to be in the SPF record or has to sign as your domain, or it fails the same way. Stay on p=none until the daily XML already shows that mail passing.

Gmail's one-click rule is two headers. List-Unsubscribe carries an https URL, and List-Unsubscribe-Post is List-Unsubscribe=One-Click. A mailto link fails Gmail's test. Yahoo still accepts mailto, and recommends the POST method. Marketing mail needs the headers. Password resets, reservations, and form confirmations are the examples the FAQ leaves out.

List-Unsubscribe: <https://example.com/unsub>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Add the three TXT records

On a NodeRings zone the Records tab is where these go. Add record takes a name, a type, a TTL, and a value. TTL has to sit between 30 and 86400 seconds. 3600 is inside that range. @ is the apex. The rest of that screen, including the two nameservers the registrar has to point at, is in the DNS guide.

The long DKIM value is one value in the form. If a form refuses the length, split it into the two quoted strings dig already printed, 255 and then 155. Other TXT records on the apex can stay beside the SPF line. A second record that also begins with v=spf1 is the permerror from section 4.5.

If DNSSEC is on, those TXT records are signed with the same algorithm 13 key as the rest of the zone. A resolver that validates returns SERVFAIL when the DS at the registrar is a hash of a different key, and Gmail never receives the TXT. The check for a leftover DS is in the registrar still trusts the old key.

Check the records with dig

Once the zone is serving, the three queries are the whole check from your side.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

You want one SPF string, one DMARC string, and a DKIM string that starts with v=DKIM1. Two answers that both start with v=spf1 are the permerror from section 4.5.

The pass or fail is decided on a message, at Gmail and at Outlook. In Gmail, Show original prints an Authentication-Results line. You are looking for spf=pass, dkim=pass, and dmarc=pass. This run stopped at the DNS and the banners. The port 25 check showed a TCP connection and an SMTP banner. A provider that blocks outbound 25 fails the connection before any of these records are consulted.

FAQ

Do I need DMARC if I send 20 messages a day?

Gmail's rule for every sender is SPF or DKIM, plus the PTR, TLS, and the spam-rate line. DMARC is required once the domain is a bulk sender, and the FAQ says that status does not expire. Outlook.com's 550 5.7.515 is the rejection at that same 5,000-a-day line. A p=none record at 20 messages a day is one TXT, and it starts the reports before the volume arrives.

What if the domain has two SPF records?

If both begin with v=spf1, the receiver returns permerror. There is no SPF pass for DMARC to use. Delete one of them. A site-verification TXT on the same name can stay.

Does DKIM replace SPF?

At bulk volume, Gmail requires both, and Outlook.com requires both to pass. DMARC itself can pass on either one, provided that one aligns with From. The other check is still required once the domain is over the 5,000 line at those two receivers.

What if port 25 is blocked?

The TXT records can be right and the message never leaves the provider's network. From this guest, port 25 to Gmail and to Outlook accepted the connection and returned a 220 banner. That result belongs to this network. The same check, a connect and a QUIT, is how you find out whether yours will carry the mail.

Can I publish p=reject on the first day?

You can, and the reports will list what you refused. A list that edits the body, a forwarder whose address is outside the SPF record, and a SaaS sender that uses your From without signing as you, all fail DMARC. p=none collects that list while the mail still goes through. Move to quarantine with a pct under 100, then to reject, after the daily XML matches the senders you expect.