Three DNS records decide whether the world's mail servers believe an email that says it is from your company: SPF, DKIM and DMARC. They are free to publish, they take an afternoon, and in the businesses we talk to they are the item left half done more often than any other. This post explains each one in plain words, what breaks when one is missing, how to read your own records, and what the big mailbox providers now require. It is written for the owner or office manager who has heard the acronyms and would like to stop nodding.
The one-paragraph version
Email was designed without a way to prove who sent a message, so the From line is a claim, not a fact. SPF says which servers are allowed to send mail for your domain. DKIM puts a cryptographic signature on each message so a receiver can check it was not changed on the way. DMARC ties the two to the address a person sees and tells receivers what to do when neither check lines up: take no action, treat it as suspicious, or reject it. Receivers such as Gmail and Outlook read the three records in your DNS and decide, usually within seconds, whether your message reaches the inbox, the spam folder, or nowhere.
SPF: who is allowed to send as you
SPF, the Sender Policy Framework, is a TXT record (a plain text entry) in your domain's DNS listing the mail servers permitted to send on your behalf. Microsoft's documentation puts it plainly: "The primary purpose of SPF is to validate email sources for a domain." A receiving server looks up the record and checks whether the server that just connected is on the list.
Two details trip people up. First, SPF checks the hidden return address used in the transmission, which Microsoft describes as "the MAIL FROM address, 5321.MailFrom address, P1 sender, or envelope sender," not the From line a reader sees in the inbox. That is why SPF on its own does not stop someone from putting your name in the visible From field; DMARC closes that gap below. Second, the record has a hard budget: the standard says "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation," which in practice means ten DNS lookups.
Microsoft adds that when the count "is greater than 10, the message fails SPF with a permanent error." A business that has added an email marketing tool, a CRM, a helpdesk, an invoicing system and a website form over the years can cross ten without noticing, and from that day its SPF fails at each receiver that checks.
The last word of the record matters too. A record ending in -all tells receivers that anything not listed is unauthorized; the standard calls that "an explicit statement that the client is not authorized to use the domain." A record ending in ~all is a softfail, a weaker statement that the sender is probably not authorized; the standard says it "ought to be treated as somewhere between" a fail and a neutral result. Microsoft recommends -all for Microsoft 365 domains because, with DKIM and DMARC in place, a hard SPF fail lets DMARC act on a message that also lacks a DKIM signature; Google's setup guide uses ~all in its example. Either is defensible; what is not defensible is a record you have not looked at since the domain was registered.
What breaks without SPF: your mail is more likely to be scored as spam, and anyone can send as your domain with no first check against them.
DKIM: a seal that shows the message was not altered
DKIM, DomainKeys Identified Mail, signs each outgoing message with a private key held by your mail system and publishes the matching public key in DNS. Google's one-line version: "DKIM helps protect your domain against spoofing by authenticating your email with a DKIM signature." The receiver fetches the public key, checks the signature, and knows two things: the message was sent by a system holding your key, and the signed parts were not changed in transit.
DKIM has one well-known weak spot. The standard itself notes that "Some mail systems modify email in transit, potentially invalidating a signature." Google's troubleshooting page says the same about forwarding: "Even when DKIM is correctly set up for your domain, forwarded messages can fail DKIM." A mailing list that adds a footer, or a forwarding rule that rewrites the subject, can break the signature through no fault of yours. This is the reason DMARC accepts either SPF or DKIM passing, rather than demanding both.
Key length is the other setting to check. The standard requires "RSA keys of at least 1024 bits for long-lived keys," and Google's setup page says "If your domain provider supports 2048-bit keys, select this option." Microsoft 365 generates 1024-bit keys by default and offers 2048 as an option.
One fact surprises many Microsoft 365 customers: your custom domain is not signed until an admin turns it on. Microsoft's documentation states that "no DKIM signing occurs for outbound mail from custom domains, so you need to do the following steps," which are two CNAME records in DNS and a switch in the Defender portal. Mail from the built-in onmicrosoft.com address is signed automatically; mail from yourcompany.com is not until someone does the work. Google Workspace is similar: the admin generates a key in the Admin console, adds it to DNS, and clicks "Start authentication." Google's test is simple: "If the message header doesn't include a line about DKIM, messages sent from your domain aren't signed with DKIM."
What breaks without DKIM: a receiver cannot tell your real mail from a forgery with your name on it, and DMARC has to lean on SPF alone, which forwarding and some third-party tools break.
DMARC: the policy that ties it together
DMARC, Domain-based Message Authentication, Reporting and Conformance, is the record that connects SPF and DKIM to the address people see. In the words of the DMARC RFC, DMARC "authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier." Translated: the domain in the visible From line has to match the domain that passed SPF or the domain that signed with DKIM. If a message claims to be from yourcompany.com and neither check lines up with yourcompany.com, DMARC fails, and your policy tells the receiver what to do.
There are three policies. With p=none, "The Domain Owner requests no specific action be taken regarding delivery of messages"; you are watching, not enforcing. With p=quarantine, failing mail should "be treated by Mail Receivers as suspicious," which usually means the spam folder. With p=reject, the owner "wishes for Mail Receivers to reject email that fails the DMARC mechanism check," and the message is refused outright. The record can also name an address for aggregate reports, the rua tag, so receivers send you a daily summary of who is sending as your domain and whether it passed. Those reports are how you find the forgotten invoicing tool before you turn enforcement on.
Google's rollout advice is the standard path: "Start with a policy set to none." Then, "After monitoring DMARC reports for at least a week and seeing no issues with your outgoing email," move to quarantine for a share of messages, and to reject when the reports are clean. The mistake in the other direction is also common: publishing p=reject on day one and discovering the next morning that the payroll provider sends as your domain and the record did not list it.
What the numbers say: the published figures come from DMARC vendors, so read them as a direction rather than a census. EasyDMARC's 2026 report on the top 1.8 million domains found that "52.1%" had valid DMARC records and "29.2%" used p=none. Valimail's 2026 release says that while "78% of domains now have a DMARC record," enforcement "has plateaued at just 42 percent." The pattern in those reports matches what we see in Microsoft 365 and Google Workspace tenants: the record is there, the policy is none, and the reports go unread.
What breaks without DMARC: no record ties SPF or DKIM to the From line a reader sees, so a forged message that passes neither check is still delivered, and you receive no reports about who is sending as you.
What the mailbox providers now require
Since February 1, 2024, Google's sender guidelines state that "all email senders who send email to Gmail accounts must meet the requirements," and the baseline for any sender is to "Set up SPF or DKIM email authentication for your sending domains." Senders of more than 5,000 messages a day to Gmail must have SPF and DKIM, must "Set up DMARC email authentication for your sending domain," and may keep the policy at none. Google also requires of those senders that "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain."
Yahoo's standards from the same month ask each sender to "Implement SPF or DKIM at a minimum" and bulk senders to "Publish a valid DMARC policy with at least p=none."
Microsoft followed for consumer Outlook.com. Its postmaster policy reads: "Effective May 5th, 2025, specific authentication requirements are in place for high-volume senders." It continues: "Domains sending more than 5,000 emails per day to Outlook.com accounts must fully be compliant with SPF, DKIM, and DMARC," with DMARC "At least p=none (p=reject is recommended)." Messages that do not meet the bar "will be sent to the junk folder," and if unresolved "may be rejected." Microsoft adds that it strongly recommends "all senders implement SPF, DKIM, and DMARC."
A 20-person business rarely sends 5,000 messages a day, so the hard requirement rarely binds it. The soft requirement does: the same filters that enforce the rule for bulk senders score the rest of us too, and a domain with SPF, DKIM and a DMARC record its own mail passes starts each conversation with a better reputation than one without.
The oldest controls in the stack, and why small and medium companies still fail them
None of this is new. SPF's first RFC dates to 2006, DKIM's to 2007 and DMARC's to 2015 (the DMARC specification itself was published in 2012); they are the first signals a receiving system reads about a message, before it looks at content. That age is the problem for a small or medium company. The records assume someone is maintaining them, and a 20-person firm with no dedicated IT staff usually inherited a domain somebody set up years ago, with an SPF record that lists the mail host and little else.
The failure pattern repeats from one company to the next. The company signs up for a tool that sends email on its behalf: an invoicing system, a scheduling app, a payroll provider, a newsletter platform, the website's contact form. The tool sends with the company's name in the From line. No admin adds the tool to the SPF record or publishes the DKIM key the tool asked for, so that mail fails SPF, fails DKIM, and therefore fails DMARC alignment. If the company's DMARC policy is none, the receivers deliver it with a lower score and the aggregate reports, which go unread, record the failure. If the policy is quarantine or reject, the company's own invoices start landing in customers' spam folders or bouncing, and the first sign is a client asking why the bill did not arrive.
The problem runs in both directions. If your business receives mail from small suppliers, contractors or clients, some of them will have exactly this gap. A receiving filter that enforces strict handling of authentication failures will quarantine or refuse their legitimate mail: the subcontractor's estimate, the accountant's reminder, the customer's purchase order. That is one reason a quarantine needs a person who reads it, and why the strictness setting on your own inbound filter is a judgment call rather than a default. A good filter uses the authentication result as one signal among many, and whoever reads the quarantine needs to tell a misconfigured small company from an attacker.
The practical rule for a small or medium company: keep a list of each service that sends as your domain, and add each one to SPF or use its DKIM signing where offered. Read the DMARC reports for a month, longer than Google's one-week minimum, before moving past none, and recheck the list each time a new tool is signed up for. For the business on the receiving end: before tightening how your filter treats DMARC failures, look at who is failing today; a share of them will be your own suppliers.
How to read your own records in ten minutes
Type your domain into any public DNS lookup tool (search for "DNS lookup," pick TXT as the record type) and read the results. The SPF record starts with v=spf1; count the terms that start with include:, a, mx, ptr, exists: or redirect=, since each one costs one of the ten lookups, and read the last word. The DMARC record lives at _dmarc.yourdomain.com and starts with v=DMARC1; read the p= value and whether a rua= address is present and goes to a mailbox someone checks. For DKIM, send a message from your work account to a personal Gmail account, open it there, click the three dots and choose Show original; the top of that page lists SPF, DKIM and DMARC as PASS or FAIL, and Google's test applies: no DKIM line means no signing. If you run Microsoft 365, the Defender portal's email authentication pages show the same settings; in Google Workspace the DKIM setting is under Apps, Google Workspace, Gmail, Authenticate email.
Write down three things: how many sending services your SPF record names, what your DMARC policy says, and whether your custom domain is DKIM signed. If one of the three is missing, the fix is a DNS record and, for DKIM, a switch in the Defender portal or the Admin console; it is not a purchase.
Where a filter fits, and where it does not
SPF, DKIM and DMARC protect your domain's reputation and make it harder for someone to send as you. They do not inspect the mail arriving in your staff's inboxes; that is the job of the filter in front of the mailbox, which reads the authentication results of inbound messages among many other signals. Check Point's documentation, for example, notes that "By default, No extra action is selected for DMARC failed emails in the Anti-Phishing security engine," and lets an admin change that. The records and the filter are two different layers. A business with a strong DMARC policy and no inbound filter is still exposed to a convincing message from a look-alike domain, and a business with a strong filter and no DMARC still lets others impersonate it to its customers.
How to start
If you would rather have someone else read the records, our Managed Email Security includes a one-time SaaS security posture report of your Microsoft 365 or Google Workspace tenant within the first 90 days. Your SPF, DKIM and DMARC records are three of the items on it, with what we found and what we recommend. The service is $6.40 per user per month on the year-end offer ($5.60 for registered 501(c)(3) nonprofits; $8 list). The offer is 20% off (30% for registered 501(c)(3) nonprofits) on a 12-month Managed Email Security agreement signed by December 31, 2026, new customers only, no onboarding fee. If you already run Check Point or another product yourself and only want the license, the license-only route is priced against the written quote you hold. Either way the first step is the free two-week email security assessment. We work with small and medium businesses and nonprofits nationwide, including Washington DC, Northern Virginia, and Maryland. To start, book a free 15-minute call, or see the services page.
Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC, 2015); Microsoft Learn, "Set up SPF" and "Set up DKIM" for Microsoft 365 (updated July 2026); Google Workspace Admin Help, "Set up SPF," "Set up DKIM," "Troubleshoot DKIM issues," "Recommended DMARC rollout" (updated October 2026); Google "Email sender guidelines" (requirements effective February 1, 2024); Yahoo Sender Hub best practices; Microsoft Outlook.com Postmaster policies (high-volume sender requirements effective May 5, 2025); EasyDMARC 2026 DMARC Adoption and Enforcement Report and Valimail 2026 State of DMARC (vendor reports); Check Point Harmony Email & Collaboration knowledge content, "Blocking emails that fail DMARC." RFC 7489 has since been superseded by RFC 9989.
