SPF, DKIM and DMARC Explained: Keeping System Email Out of the Spam Folder

On Monday morning the customer service team posts in the group chat: several users have called to say their OTP never arrived. The IT team opens the system logs and finds every email went out, with not a single error. The real problem is at the other end. The emails reached the recipients, but they were filed in a spam folder nobody checks.

The most common cause of this symptom is a sending domain that has not fully proved who it is. SPF is the list that tells receivers which servers may send email on behalf of your domain. DKIM is a digital signature attached to each email, so the receiver can check that the message really came from that domain and was not altered on the way. DMARC is the policy that tells receivers what to do when an email claiming to be from your domain fails those checks, and asks them to send reports back.

This article is for the people who run systems that send email in their organization's name: OTPs, invoices, notifications. We explain why this moved from good practice to a condition set by the large mailbox providers, where organizations tend to slip because they have more senders than they think, and how to tighten DMARC without losing legitimate mail along the way. It does not walk through DNS settings step by step, because those differ by provider. It aims to tell you what you need to decide before you touch anything.

What SPF, DKIM and DMARC are, and how they fit together

SPF is defined in RFC 7208. The domain owner publishes in DNS the servers or services allowed to send mail for the domain, and the receiver checks whether an incoming message came from one of them. One limit is easy to forget: RFC 7208 caps the number of terms that trigger DNS lookups during an SPF check at 10. Go over it and the result is a permerror, even if the sending server is on the list.

DKIM is defined in RFC 6376. The sending system signs each message with a private key and publishes the public key in DNS, and the receiver uses that public key to verify the signature. Because the signature travels with the message, it can still be checked after the email is relayed through another server, which SPF cannot handle.

DMARC builds on the other two. It checks whether the domain that passed SPF or DKIM matches the domain the user sees in the From line, which is called alignment, and then applies the policy the domain owner has published. There are three levels: none asks for no action, quarantine asks for failing mail to be treated as spam, and reject asks for it to be refused. DMARC also asks receivers to send back summary reports showing where mail claiming to be from your domain came from, and whether it passed.

Worth knowing: DMARC has just been through a new standard. RFC 9989 was published in May 2026 on the Standards Track and obsoletes RFC 7489, which had been in use since 2015 (source: RFC 9989). Existing records keep working, but some tags have changed status, which we come back to in the section on tightening the policy.

Why this became a condition set by mailbox providers

For years SPF, DKIM and DMARC were treated as good work to do when there was time. That changed when the large mailbox providers started writing them into their conditions for accepting mail.

Google Workspace documentation states that every sender to personal Gmail accounts must set up SPF or DKIM, and that senders of more than 5,000 messages a day must set up SPF, DKIM and DMARC (source: Google Workspace, Set up DKIM, updated 20 October 2026). Google's Email sender guidelines say the requirements took effect on 1 February 2024 and ask senders to keep the spam rate reported in Postmaster Tools below 0.3%. The FAQ for the same guidelines says that from November 2025 Gmail is ramping up enforcement on non-compliant traffic, which may be rejected or sent to spam.

Yahoo applies similar rules from February 2024. Every sender needs SPF or DKIM and a spam rate below 0.3%. Bulk senders need both SPF and DKIM, a DMARC policy of at least p=none that passes, and one-click unsubscribe for marketing mail (source: Yahoo Sender Best Practices).

Microsoft announced on its Defender for Office 365 blog on 2 April 2025 that domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live must pass SPF and DKIM, with a DMARC policy of at least p=none aligned with SPF or DKIM. An update dated 29 April 2025 says non-compliant mail will be rejected with code 550 5.7.515 from 5 May 2025.

All three sets of requirements are as we found them in October 2026, and each provider can change them at short notice. Check the official pages again before quoting them in an internal document.

Your systems may never reach 5,000 messages a day, but most of your users are on Gmail or Outlook already. The baseline requirements for every sender therefore apply to your OTPs too.

A system's email does not come from one place

Setups rarely fail because the records are hard. They fail because the organization does not know everything that sends mail in its name. RFC 9989 says so plainly: in all but the most trivial setups, a domain owner can overlook a server here, or be unaware of a third-party sending agreement there.

In a mid-size organization or larger, the list of senders is usually longer than the IT team expects. Staff email runs on Microsoft 365 or Google Workspace. The core system sends OTPs through an SMTP relay or a cloud email service. The CRM sends quotations, the HR system sends payslips, the ticketing system sends notifications, and the marketing team uses yet another newsletter tool. Each one must be listed in SPF or sign with DKIM using a domain aligned with the sender's domain, or DMARC will fail.

Three patterns come up again and again. A new system installed by a vendor sends mail in the organization's name from day one, but nobody adds it to SPF. SPF includes so many services that it passes the 10-lookup limit and the whole record fails. An outside service signs DKIM with its own domain, so DKIM passes but DMARC fails because the domain does not match the From line.

All three have one cause: nobody holds the list of senders.

So the first job is an inventory, not a DNS change. Work out which system sends mail for which domain, through which service, and who owns each system. If a vendor runs the system, ask them directly which service it sends through and whether it can sign DKIM with your domain. That question belongs on the checklist when you take over a system from a vendor, alongside the others in our article Before Hiring a Software Vendor: Assessing the Risk They Disappear.

Should system email use its own domain or subdomain?

Mailbox providers judge sender reputation by domain as well. If OTPs, newsletters and staff email all share one domain, a marketing campaign that draws a lot of spam reports can drag the domain's reputation down far enough that the OTPs land in spam too.

Our view is that if the organization sends marketing email in volume, separate subdomains per type of mail are worth it: one subdomain for transactional mail such as OTPs and invoices, another for newsletters, and the main domain kept for staff. That way a problem in one stream does not spill into another, and DMARC reports are easier to read by type.

If the organization only sends staff email and a modest volume of OTPs, with no marketing mail at all, a separate domain may not be needed. What matters more in that case is getting every stream through SPF, DKIM and DMARC first.

Move DMARC from none to quarantine to reject one step at a time

RFC 9989 recommends that domain owners start at p=none with a mailbox for reports, a state it calls Monitoring Mode. The point is to make sure nothing was missed in the first round of SPF and DKIM setup. The reports show where mail claiming to be from your domain is coming from, including legitimate streams that are not yet configured and anyone spoofing the domain.

The reports are designed to be read by machines, and RFC 9989 itself recommends parsing them with a tool, whether a third-party service or something built in-house. A reports mailbox that nobody reads means DMARC is published and doing nothing. A named person needs to own reading the reports and chasing down the streams that fail.

On timing, the two main sources do not agree. Google Workspace's rollout guide recommends setting up SPF and DKIM at least 48 hours before DMARC, staying at p=none for one week, then moving to quarantine using the pct tag at a small percentage and raising it over time (source: Google Workspace, Recommended DMARC rollout, updated 15 October 2026). RFC 9989 says that, depending on how often the organization sends mail, it may take many months of reading reports before the owner is sure all mail is authenticated, and it moves the pct tag to historic status, with a new t tag for test mode.

In practice the deciding factor is how many streams send mail. An organization with only Workspace and one system may see the full picture within a few weeks. An organization with monthly mail runs, such as month-end invoices or quarterly reports, should wait for at least one of those cycles to pass before tightening the policy. Before relying on pct, check whether your provider still honors it or has moved to the new tag.

One caution at the reject stage: some legitimate mail can fail DMARC even when everything is set up correctly, for example mail passing through a mailing list that alters the message. RFC 9989 therefore asks receivers not to reject mail solely because the policy says reject, but domain owners should not count on that. Move to reject only after the reports show every legitimate stream is passing.

Who controls the organization's DNS and domain

Every step above means changing DNS. If the account that manages DNS sits with a vendor or a former hosting provider, every new sending service or policy change has to wait for someone outside the organization. This tends to surface when OTPs stop arriving and the fix has to land the same day.

In our article on writing a TOR for a system you can maintain (in Thai), we argue that domain names should be registered to the organization from day one. The same principle applies to the DNS account: the organization should own it, and outside administrators should work in it as users the organization has granted access to. Managing that access when a team changes is covered in Who Actually Holds the Keys to Your Cloud Account?

It is also worth setting an approval step for DNS changes, especially SPF and DMARC, because one wrong record can make the whole organization's mail fail. Who can request a change, who approves it, and who checks the result afterwards should be written down, rather than left to whoever has the password.

Measure whether mail actually reaches the inbox

Once everything is set up, you need a way to know it still works. There are two main sources. DMARC reports show the share of mail passing and failing, broken down by origin. Google Postmaster Tools shows spam rate, domain reputation, authentication results and delivery errors for mail sent to Gmail users. One limitation: if the organization sends little mail per day, Postmaster Tools may show no data.

The number worth alerting on is the share of mail from legitimate streams that fails DMARC. If it jumps on a given day, it usually means a new system has started sending mail or someone has changed DNS incorrectly. How to route alerts to the person who needs to act, without waking the team for nothing, is covered in Monitoring and Alerts That Wake You Only for What Matters.

A check you can run today is to open the headers of an OTP sent to a test Gmail or Outlook account and read the SPF, DKIM and DMARC results the receiver recorded. Repeat it every time you add a new sending service.

The limits, stated plainly

Having SPF, DKIM and DMARC fully in place does not mean every email reaches the inbox. Providers still weigh content, domain reputation and how many people mark your mail as spam. RFC 9989 itself says that a DMARC pass only shows the use of the domain was authorized, and says nothing about the quality of the message.

DMARC stops outsiders from spoofing your domain, but it cannot stop mail sent from a genuine account in your organization that has been compromised, because that mail passes every check. Protecting accounts, for example with MFA, is separate work that still has to be done.

If your organization only sends staff email through Workspace or Microsoft 365, with no other system sending in the domain's name, most of this article leaves little to do: turn on DKIM in the mail service you already use and publish DMARC at p=none to read the reports. Moving all the way to reject can be quick in that case, because there are only a few streams to check.

Where to start

Start with an inventory of every system that sends mail in the organization's name, with the owner of each. Then check that each stream passes SPF or DKIM with an aligned domain, publish DMARC at p=none with a reports mailbox, and name the person who reads the reports. Once the reports show every legitimate stream passing, tighten the policy one step at a time.

If your OTPs are landing in spam today, start by opening the headers of one of those emails. The results recorded there usually tell you what is missing.

Summary

Most OTPs that never arrive were not lost on the way. They were filtered out because the domain could not prove who it was. If you take one thing from this article, make a list of every system that sends mail in your organization's name, because every remaining step depends on that list.

If your organization has several systems sending mail under the same domain and you would like help building the inventory and reading the first DMARC reports, we are happy to talk. No fixed deadline, and no rush to decide.

To discuss a project in detail, reach us at 088-983-9386 or email [email protected]. Our office is in Bang Kapi, Bangkok. For organizations reviewing how their systems send email, we are glad to set up a call to understand the problem first, and if it turns out what you have is already enough, we will say so plainly.