Abusive email often puts the domain of an organization the recipient knows and trusts into the visible From header[1]. SPF and DKIM authenticate mail at the domain level; DMARC ties their results to the From domain the recipient actually sees, lets the domain owner publish in DNS how it would like failures handled, and asks receivers to send back reports[1]. Phishing and business email compromise gives a short introduction to what each one does. This guide covers deployment: find every system that sends mail as your company, set up SPF and DKIM for each, raise DMARC step by step from monitoring to reject, and lock down the domains that never send mail.

This is no longer just a recommendation. Gmail and Yahoo have required bulk senders to use SPF, DKIM and DMARC since February 2024[2][3], and Outlook.com followed in May 2025[4]. A company that sends newsletters or high volumes of notifications without them may see mail land in spam or bounce. This guide is for IT staff who run DNS and mail systems, and for managers who need to approve the rollout timeline.

Start with an inventory: who sends mail as your domain

Once DMARC moves to quarantine or reject, any legitimate sender that is not set up correctly gets blocked along with the forgeries, so the first step is an inventory. RFC 9989 warns that in all but the most trivial setups, a domain owner can easily overlook a server or be unaware of a third party sending on its behalf[1]. Typical senders include company mailboxes (Microsoft 365, Google Workspace or an on-premises mail server), newsletter platforms and CRM, e-invoicing and billing notices, helpdesk ticketing, website forms and e-commerce order notices, recruiting and event registration systems, and internal devices and programs such as scan-to-email on multifunction printers, monitoring alerts and scheduled ERP reports.

Use three methods together: check which services the existing SPF record already includes; ask procurement and each department to list every SaaS contract that sends mail in the company's name; and after publishing a p=none DMARC record, use the aggregate reports to find sources missing from the list (see below). For each source, record the owner, the sending domain, how SPF is set up, whether it can DKIM-sign with your domain, and whether it supports a custom bounce (Return-Path) domain.

For services outside IT's direct control, such as high-volume marketing mail, Microsoft recommends sending from a subdomain (for example marketing.example.com) so problems with that mail do not drag down the reputation of the main domain; each subdomain also gets its own SPF record and DNS lookup budget[5][6].

SPF and DKIM: set up every sender

SPF: one record, ten lookups

SPF is a TXT record on your domain that lists the servers allowed to use the domain as the envelope sender (MAIL FROM); most Microsoft 365 organizations, for example, need v=spf1 include:spf.protection.outlook.com -all[5]. DMARC uses only SPF's result for the envelope sender domain[1]; whether that domain matches the From domain the recipient sees is the "alignment" question in the next section. The most common pitfalls:

  1. One SPF record per domain: if more than one record starting with v=spf1 is found, the result is permerror[7]. When adding a service, merge its include into the existing record instead of following the vendor's instructions to add another one.
  2. No more than 10 DNS lookups in total: include, a, mx, ptr, exists and redirect all trigger DNS queries, and exceeding 10 returns permerror; ip4, ip6 and all do not count[7]. Includes nested inside included records count too, so fewer than 10 includes does not guarantee fewer than 10 lookups[5]. Receivers should also limit "void lookups" that return no data to two, and exceeding that is also a permerror[7]; an include that points to a domain with no SPF record also causes permerror, so remove includes for services you retire[5].
  3. When you exceed the limit: Microsoft suggests moving third-party services to subdomains (each subdomain gets its own 10-lookup budget), consolidating sending services, or replacing includes with ip4/ip6 for vendors that have stable, documented IP addresses. This "flattening" is not suitable for cloud services whose IP addresses change often, such as Microsoft 365; if you do flatten, check the vendor's published addresses at least quarterly[5].
  4. ~all or -all: -all (fail) is an explicit statement that unlisted hosts are not authorized to use the domain; ~all (softfail) is a weak statement that the host is probably not authorized, and the standard says receivers should not reject on softfail alone[7]. Microsoft recommends -all for domains that also have DKIM and DMARC[5].

SPF has a built-in limitation: after forwarding or relaying through an alias address, the connecting IP is no longer the original sending server, so SPF usually fails while DKIM signatures generally remain valid[1]. That is why DMARC cannot rely on SPF alone.

DKIM: a separate key for each service

With DKIM, the sender signs each message with a private key and the receiver fetches the public key from selector._domainkey.example.com in DNS to verify it[6]. Key points:

  • Every sending service must sign with your domain: many hosted mail services sign with their own service domain by default and add a signature with the customer's domain only after the customer configures it[6]. In Microsoft 365, for example, custom domains are currently not DKIM-signed by default; you must create the selector1 and selector2 CNAME records in DNS and then enable signing[6].
  • Key length: mail to personal Gmail accounts requires a DKIM key of at least 1024 bits, and Google recommends 2048 bits if your DNS provider supports it[2].
  • Do not share keys: M3AAWG does not recommend sharing the same DKIM keys across several entities[8]. Give each service its own selector so it can be withdrawn on its own when you stop using that service.
  • Rotate regularly: M3AAWG recommends rotating keys at least every six months[8]. Publish the new selector's public key first, start signing with the new private key after DNS has propagated, and keep the old public key long enough for mail in transit to be verified before removing it[8]. Third-party services often use CNAME records that point your selectors to keys the provider manages, so the provider can rotate keys without asking you to edit DNS each time[8].

DMARC: from monitoring to reject

A DMARC record is a TXT record published at _dmarc.example.com[1]. The current standard is RFC 9989, published in May 2026, which obsoletes RFC 7489; the aggregate report format is defined separately in RFC 9990[1][9]. Keep in mind that a DMARC policy is only a handling request: receivers may choose not to follow it, and a DMARC pass only means use of the domain was authorized, not that the message is safe[1].

Alignment: relaxed and strict

A message passes DMARC when SPF or DKIM passes and the authenticated domain "aligns" with the From domain[1]. Relaxed alignment only requires both to share the same organizational domain, for example a DKIM signature from mail.example.com on a message from news.example.com; strict alignment requires them to be identical. Relaxed is the default (adkim=r, aspf=r), and RFC 9989 notes that nearly all domain owners have found relaxed alignment sufficient[1].

A common finding in reports is SPF or DKIM showing pass while DMARC fails: a third-party service passes SPF with its own bounce domain and signs DKIM with its own domain, and neither aligns with your From domain. The fix is to configure a custom bounce domain in that service, or enable DKIM signing with your domain. RFC 9989 recommends using both SPF and DKIM so each message produces at least one, and preferably two, aligned results[1].

Raising the policy in stages

The sequence RFC 9989 recommends is: once SPF, DKIM and a reporting mailbox are in place, start in monitoring mode with p=none and an rua address, and use the reports to audit your own mail streams; legitimate streams that fail must be fixed before moving to an enforcement policy[1]. Depending on how often you send, it can take many months of reports before you are sure all mail is properly authenticated[1]. The record can evolve like this (replace example.com with your own domain):

  1. Monitor: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
  2. Quarantine, testing: v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com
  3. Quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
  4. Reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

t=y is a testing flag introduced in RFC 9989: with p=quarantine and t=y, receivers apply the next level down, none; with p=reject and t=y, they apply quarantine[1]. It replaces the old pct tag, because pct was rarely applied accurately for values other than 0 and 100, and the new standard lists pct as historic[1]; the old approach of raising the pct percentage step by step no longer applies under the new standard. Whether receivers have adopted the t tag yet is something to confirm from the disposition they actually applied, as shown in the reports[9].

Before moving to reject, RFC 9989 makes two points: a domain publishing reject must not rely on SPF alone and must apply valid DKIM signatures; and domains whose users might post to Internet mailing lists should not publish reject, and if they still want to, they should first run p=none for at least a month, then quarantine for an equally long period, compare the results, and tell users that mailing list participation may be affected[1]. Before rolling out, find out which colleagues use company addresses on external mailing lists, such as open-source projects. A government precedent can serve as a timeline reference: BOD 18-01, issued by the US Department of Homeland Security in October 2017, required federal agencies to publish DMARC records with at least p=none and a designated report recipient for all second-level domains within 90 days, and to set reject for all second-level domains and mail-sending hosts within one year[10].

Subdomain policy

Unless set otherwise, the main domain's p also applies to subdomains; sp= sets the policy for existing subdomains, and np=, new in RFC 9989, sets the policy for non-existent subdomains, falling back to sp and then p when absent[1]. For example, if the main domain is still in its quarantine observation period but you want to reject mail forging subdomains that were never created, such as invoice.example.com, publish v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com. A subdomain can also publish its own _dmarc record that overrides the parent's settings[6]; if you delegate a subdomain to a third party, it could add a DMARC record that overrides the main domain's policy, so M3AAWG recommends auditing all delegated domains[8].

Reading aggregate reports

Aggregate reports are XML files that receivers send daily (or more often), preferably gzip-compressed[9]. Each report covers a single domain and includes the policy the receiver discovered and applied, the disposition it chose, the domains SPF and DKIM evaluated and their results, whether each aligned, and the message count for each source IP[9]. The format is meant for machine parsing, and RFC 9989 suggests using a third-party service or your own tools[1]. Sort what you find by source: known services that pass just need watching; known services that fail usually lack alignment or DKIM, and must be cleared before enforcement; forwarded mail where SPF fails but DKIM still passes and aligns passes DMARC anyway and needs no action[1]; and unknown sources that fail may be forgeries or forgotten systems, so check them against the inventory and the IP owner.

If rua points to another domain, such as an external report analysis service, the receiving domain must publish an authorization record at example.com._report._dmarc.<report-service-domain>, or receivers will ignore that address; a dedicated report service can use a wildcard record to authorize all domains at once[9]. The other report type, failure reports (ruf), can include much of the message body and headers, which risks unintended exposure of personal data; CISA notes that only a handful of providers send them[10], and Microsoft says Outlook.com has no plans to send ruf[4]. In most cases rua alone is enough.

Lock down domains that never send mail

Defensive look-alike registrations, old brand domains and website-only domains can all be used to send forged mail. For these "parked" domains that neither send nor receive mail, M3AAWG recommends publishing all of the following[11]:

  • SPF: v=spf1 -all, meaning no IP may send mail for the domain.
  • DKIM: publish no keys at all, so a forged signature can never validate.
  • DMARC: publish v=DMARC1; p=reject; at _dmarc; rua is optional, but must point to another domain that does receive mail.
  • Null MX: MX 0 . (a bare dot on the right-hand side), meaning the domain accepts no mail.
  • Subdomains: use the wildcard *.example.com to publish v=spf1 -all and null MX as well.

With many domains, each domain's _dmarc can be a CNAME pointing to one centrally managed reject record[11]. This set of records is only for domains that neither send nor receive mail[11]; for your main domain, which is still in use, the np=reject setting from the previous section protects non-existent subdomains.

Mailbox provider requirements and next steps

Gmail, Yahoo and Outlook.com

Since 2024, the major mailbox providers have made authentication a condition of delivery, with the strictest rules aimed at bulk senders:

  • Gmail: since 1 February 2024, everyone sending to personal Gmail accounts must set up SPF or DKIM, have valid forward and reverse DNS (PTR) records for sending domains or IPs, use TLS, and keep the spam rate reported in Postmaster Tools below 0.3%; senders of 5,000 or more messages a day must also set up both SPF and DKIM, publish DMARC (the policy can be none), align the From domain with the SPF or DKIM domain, and support one-click unsubscribe with a clearly visible unsubscribe link in marketing and subscribed messages[2]. Google counts all messages from the same primary domain, subdomains included, toward the 5,000 figure, and anyone who reaches it once is permanently classified as a bulk sender; since November 2025 Gmail has been ramping up enforcement, and non-compliant messages face disruptions including temporary and permanent rejection[12].
  • Yahoo: enforced in phases from February 2024; all senders need at least SPF or DKIM and a spam rate below 0.3%; bulk senders need both SPF and DKIM, a valid DMARC policy of at least p=none that passes (an rua tag is strongly recommended and relaxed alignment is acceptable), one-click unsubscribe, and must honor unsubscribes within 2 days[3].
  • Outlook.com: Microsoft announced in April 2025 that domains sending more than 5,000 messages a day to its consumer addresses (hotmail.com, live.com, outlook.com) must pass SPF and DKIM and have DMARC of at least p=none aligned with SPF or DKIM; an update on 29 April changed the action to outright rejection of non-compliant mail (error 550 5.7.515), effective 5 May 2025[4].

All three accept p=none as the minimum, but none means the domain owner offers no expression of preference[1]: it gets you through the door, but it does not stop anyone spoofing your domain.

Next steps: MTA-STS, TLS-RPT and BIMI

SPF, DKIM and DMARC deal with others sending mail as your domain. Once they are in place, two more items are worth evaluating:

  • MTA-STS and TLS-RPT: protect encryption of mail sent to you while in transit. MTA-STS lets a receiving domain declare that it supports TLS and that sending servers should refuse to deliver to MX hosts that do not offer TLS with a trusted certificate; you publish a TXT record at _mta-sts.example.com and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt, with a mode of testing, enforce or none[13]. In testing mode mail is still delivered, while senders that also support TLS-RPT report validation failures, so observe first and then switch to enforce[13].
  • BIMI: shows your brand logo in supporting mailboxes. For Gmail, the DMARC policy must be quarantine or reject (none is not supported) and apply to all messages, and you need a VMC or CMC certificate from a certificate authority; a VMC requires a trademarked logo, and trademark registration can take 6 to 12 months[14]. Treat BIMI as a reward for reaching DMARC enforcement.

Action checklist

  • List every domain the company owns, including defensive registrations, old brands and website-only domains, and check their SPF, DKIM, DMARC and MX records; give non-sending domains v=spf1 -all, a p=reject DMARC record and null MX in one go.
  • Build a sender inventory: service, owner, sending domain, SPF method, DKIM selector, and whether a custom bounce domain is supported; add "does it send mail?" to the procurement checklist for new SaaS.
  • Make sure each domain has exactly one SPF record with no more than 10 DNS lookups; move third-party marketing mail to subdomains.
  • Enable DKIM with your own domain for every sending service (custom domains in Microsoft 365 must be enabled manually), prefer 2048-bit keys, and put six-monthly rotation on the operations calendar.
  • This week, publish a p=none DMARC record with rua, pick a report analysis tool, and review reports weekly to fix legitimate sources that do not align.
  • Set a timeline and an owner for moving from none to quarantine to reject, add np, and before going to reject confirm that every source has an aligned DKIM signature.
  • Have departments that send newsletters or bulk notifications check their unsubscribe handling and spam rates against the Gmail, Yahoo and Outlook.com requirements.
  • Once DMARC is at enforcement, evaluate MTA-STS, TLS-RPT and BIMI; if you need outside help reviewing mail and DNS settings, see the security health check, and follow phishing advisories for real cases of domain spoofing.