SPF, DKIM, and DMARC Explained: Stop Spoofing and Keep Your Email Delivering

If someone can send email that says it comes from your domain, they can bill your customers, redirect vendor payments, or phish your staff in your name. DMARC, working with SPF and DKIM, is how you tell the rest of the internet which mail really comes from you and what to do with everything else. Gmail and Yahoo have required these records from bulk senders since 2024, and Outlook.com followed in 2025. This guide covers what each record does, how they fit together, what the big mailbox providers require, and a safe path from monitoring to blocking.

Sources: Google email sender guidelines FAQ, Microsoft Outlook.com high-volume sender requirements, Yahoo Sender Hub, and RFC 7208 (SPF).

Why email needs SPF, DKIM, and DMARC

Email was designed without sender checks. Microsoft’s email authentication overview says SMTP “makes no effort to validate that the message sender is who they claim to be.”

Every message has two sender addresses. The envelope sender (the MAIL FROM address) is used between mail servers, and recipients never see it. The From address is the one people see in Outlook or Gmail. A criminal can put their own domain in the envelope and your domain in the From line. Microsoft calls that “a classic example of spoofing.”

That matters for three reasons:

• Spoofing: customers, vendors, and staff receive convincing fake mail that appears to come from you.
• Business email compromise (BEC): Microsoft notes that spoofed senders “are commonly used in business email compromise (BEC), phishing, and other email attacks.” A fake invoice or payment-change request is more convincing when the From address is exactly right. Our business email compromise guide covers how those scams work.
• Deliverability: Google says authenticated messages “are less likely to be rejected or marked as spam,” and warns that unauthenticated mail to Gmail “might be marked as spam or rejected.”

What SPF, DKIM, and DMARC each do

SPF: which servers can send for you

Sender Policy Framework, defined in RFC 7208, is a DNS TXT record that lists the servers and services allowed to send mail for your domain. The receiving server checks the sending server against that list. SPF checks the envelope (MAIL FROM) domain, not the From address people see.

Example only (example.com sends through Microsoft 365 and one outside mailer):

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.mailer.example -all"

Two rules catch a lot of people out:

• One SPF record per domain. RFC 7208 says a domain “MUST NOT have multiple records” for SPF. If a receiver finds two, the check returns a permanent error (“permerror”). When you add a new sender, edit the existing record. Don’t publish a second one.
• No more than 10 DNS lookups. Each include, a, mx, ptr, exists, and redirect counts toward a limit of 10 per check, and going over is also a permerror. ip4 and ip6 entries don’t count. Includes can contain more includes, so, as Microsoft’s SPF guide points out, having fewer than 10 include statements doesn’t guarantee fewer than 10 lookups.

SPF also breaks when mail is forwarded, because the forwarding server isn’t on your list. That’s one reason SPF alone isn’t enough.

DKIM: a signature on every message

DomainKeys Identified Mail, defined in RFC 6376, adds a digital signature to each outgoing message. Your mail system signs with a private key. The matching public key is published in DNS under a “selector” name, at selector._domainkey.yourdomain. Receivers use it to confirm which domain signed the message and that the signed parts weren’t changed in transit. The signature travels with the message, so DKIM usually survives forwarding.

Example only (the key is shortened):

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Gmail requires DKIM keys of at least 1024 bits and recommends 2048, and Yahoo says the same. On its own, a DKIM pass only proves that some domain signed the message. That domain doesn’t have to match your From address. Checking that match is DMARC’s job.

DMARC: your policy, plus reports

DMARC, defined in RFC 7489, is a TXT record at _dmarc.yourdomain. It does three things. It checks that SPF or DKIM passed for the same domain the reader sees in the From line. It tells receivers what to do when that check fails. And it asks receivers to send you reports.

Example only (monitoring mode):

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The policy (p=) has three settings: none (monitor only), quarantine (treat failures as suspicious, usually meaning the spam folder), and reject (refuse failing mail). The rua= address receives aggregate reports. These are XML summaries, typically sent once a day, showing which IP addresses sent mail as your domain and whether that mail passed.

SPF vs DKIM vs DMARC at a glance

Alignment: how DMARC ties SPF and DKIM together

A message passes DMARC when at least one of SPF or DKIM passes and the domain it passed for “aligns” with the From domain. There are two alignment modes:

• Relaxed (the default): the organizational domains must match. A message from [email protected] signed by mail.example.com passes.
• Strict: the domains must match exactly, so that same message fails DKIM alignment.

Third-party mailers usually run into trouble here. Microsoft’s DMARC guide describes the common case: a marketing or billing service sends as you, SPF passes for the service’s own bounce domain, and DMARC still fails because nothing lines up with your domain. The fix is to have the service DKIM-sign with your domain, or to set its MAIL FROM (return-path) to your domain or a subdomain.

What DMARC doesn’t stop

DMARC protects your exact domain. The specification treats display-name tricks as out of scope and says it doesn’t address “visually similar domain names,” meaning lookalikes like examp1e.com. It also can’t help when a real mailbox is taken over. A criminal sending from your own account is sending through your own servers, so the mail passes. Those risks call for MFA, sign-in monitoring, calling to verify payment changes, and good email security filtering.

Gmail, Yahoo, and Outlook.com bulk-sender requirements

Google and Yahoo started enforcing new sender rules in February 2024, and Microsoft followed for Outlook.com in May 2025. Here is what each provider’s own pages say.

Google (personal Gmail accounts)

• Bulk threshold: anyone who sends “close to 5,000 messages or more” to personal Gmail accounts within 24 hours, counting all mail from the same primary domain. Google says anyone who meets that bar once is “permanently considered” a bulk sender.
• All senders (from February 1, 2024): SPF or DKIM, valid forward and reverse DNS, TLS, and a spam rate reported in Postmaster Tools below 0.3%.
• Bulk senders: SPF and DKIM, a DMARC record (a policy of none is allowed), a From domain aligned with the SPF or DKIM domain, and one-click unsubscribe on marketing and subscribed messages.
• Enforcement: Google says that starting November 2025 it is “ramping up its enforcement,” and that failing messages will see disruptions “including temporary and permanent rejections.”
• Scope: the rules apply to mail sent to personal Gmail accounts, not to Google Workspace business accounts.

Sources: Google email sender guidelines and sender guidelines FAQ.

Yahoo (including AOL)

• Bulk threshold: someone sending “a significant volume of mail.” Yahoo says it “will not specify a volume threshold.”
• All senders: SPF or DKIM, a spam rate below 0.3%, valid forward and reverse DNS, and compliance with RFC 5321 and RFC 5322.
• Bulk senders: SPF and DKIM, a valid DMARC policy of at least p=none that passes, and a From domain aligned with SPF or DKIM. Relaxed alignment is acceptable, and a rua reporting address is “strongly recommended.” Marketing mail needs one-click unsubscribe, honored within 2 days.
• Enforcement: began February 2024 and rolled out gradually. Unsubscribe enforcement began June 2024.

Sources: Yahoo sender requirements and Yahoo Sender Hub FAQ.

Microsoft (Outlook.com, Hotmail.com, and Live.com addresses)

• Bulk threshold: domains sending more than 5,000 emails per day to Microsoft’s consumer addresses.
• Requirements: SPF must pass, DKIM must pass, and DMARC must be at least p=none and aligned with SPF or DKIM, “preferably both.”
• Enforcement: announced April 2, 2025, starting May 5, 2025. Microsoft’s April 29 update says failing messages are rejected with the error “550; 5.7.515 Access denied.” Some of Microsoft’s wording still describes sending them to Junk first, so plan for rejection.

Source: Microsoft’s Outlook.com high-volume sender announcement. Microsoft says the rules apply to Outlook.com, its consumer email service.

Under these volumes? All three providers still expect basic authentication, and Microsoft’s FAQ says “all senders benefit” from it. Also note that p=none satisfies the rule but doesn’t block anything. CISA’s BOD 18-01 guidance calls p=none “a temporary policy setting” that “is only meaningful when coupled with reporting.”

A DMARC setup path, step by step

Microsoft’s and Google’s guidance agree on the order: set up SPF and DKIM first, publish DMARC at p=none, then tighten it slowly while you read the reports.

1. List everything that sends as your domain

Start with Microsoft 365 or Google Workspace, then add your website forms, CRM and newsletter tools, invoicing and accounting software, help desk, scanners, and any business apps that send notifications. Microsoft notes that in complex organizations it’s hard to find every source, which is exactly what the reports in step 5 help with.

2. Build a single SPF record

• Start with your provider’s include: include:spf.protection.outlook.com for Microsoft 365, or include:_spf.google.com for Google Workspace.
• Add each other sending service to the same record, using the include or IP ranges that service documents.
• Count lookups. If you’re over 10, move a service to a subdomain (it gets its own record and its own limit of 10), replace a stable vendor include with its published IP addresses, or retire services you no longer use. Microsoft warns against replacing its own include with IP addresses, because those addresses change frequently.
• Finish with an all rule. Microsoft recommends -all (hard fail) for Microsoft 365 domains that also use DKIM and DMARC. Google’s examples use ~all (soft fail).

3. Turn on DKIM signing

• Microsoft 365: Microsoft says no DKIM signing with your custom domain happens until you set it up. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then the DKIM tab. Microsoft gives you two CNAME records (selector1._domainkey and selector2._domainkey). Publish them with your DNS host, then turn on “Sign messages for this domain with DKIM signatures.” New keys default to 1024 bits, and PowerShell can create or rotate to 2048-bit keys. See Set up DKIM in Microsoft 365.
• Google Workspace: In the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email. Generate a key (Google recommends 2048-bit if your DNS host supports it), publish the TXT record at google._domainkey, then click Start authentication. Google says DKIM can take up to 48 hours to start working after you add the key. See Set up DKIM in Google Workspace.
• Other senders: turn on each service’s custom-domain or DKIM option so it signs with your domain, not its own.

4. Publish DMARC at p=none with reporting

Google advises setting up SPF and DKIM at least 48 hours before DMARC. Then publish a monitoring record like the example earlier, with a rua address you actually check. Raw reports are compressed XML files. Microsoft suggests a reporting service or some automation to make them readable.

5. Read the DMARC reports and fix what you find

Each aggregate report lists sending IP addresses, message counts, and the SPF and DKIM results. Sort what you find into three groups:

• Legitimate and aligned: nothing to do.
• Legitimate but failing: often a third-party mailer that uses its own bounce domain or doesn’t sign with yours. Turn on DKIM with your domain at that service, set a custom return-path, or move it to a subdomain.
• Not yours: spoofing attempts. These are what the stricter policies will block.

Google’s rollout guidance is to review reports daily and stay at none for at least a week. Give it longer if you have many senders.

6. Move to quarantine, then reject

Microsoft’s stated goal is p=reject for all your domains, reached in stages: none, then quarantine, then reject. Microsoft suggests starting with low-volume subdomains and leaving the parent domain for last.

Example only (the later stages):

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

RFC 7489 defines a pct tag to apply the policy to only part of the failing mail during rollout. Microsoft suggests steps of 10, 25, 50, 75, and 100, and Google’s example starts at 5. Treat pct as a rough ramp, not a precise dial (see the note below).

Take care with reject. The newest standard (RFC 9989, described below) warns that domains whose users post to internet mailing lists “SHOULD NOT” publish p=reject. Domains that go ahead anyway should spend at least a month at none and an equal period at quarantine first, and must sign with DKIM rather than rely on SPF alone. For federal agencies, CISA’s BOD 18-01 required reject within one year of the 2017 directive and called it “the strongest protection against spoofed email.”

7. Lock down domains you don’t send from

Parked domains can be spoofed too. Microsoft recommends an SPF record of v=spf1 -all, a DMARC record of v=DMARC1; p=reject;, and no DKIM records for domains that never send mail.

How LTS can help

We set up and look after email authentication so your domain is protected without blocking your own mail. We can handle it for you or work alongside your IT staff.

• Email authentication review: We check your SPF, DKIM, and DMARC records, count SPF lookups, and list every service that sends as your domain.
• SPF and DKIM setup: We set up signing in Microsoft 365 or Google Workspace and in the third-party tools that send for you.
• DMARC rollout: We read the reports, fix failing senders, and move your policy from none to quarantine to reject at a pace your mail flow can handle.
• Bulk-sender checks: If you send newsletters or marketing mail, we check it against the current Gmail, Yahoo, and Outlook.com requirements.
• Ongoing care: Monitoring and changes as part of our cybersecurity services, Microsoft 365 services, and managed IT support.

Not sure what your domain publishes today? Request an email authentication review.

Related: Business email compromise · Cybersecurity services · Microsoft 365 services · Contact