Who is sending email in your company's name

The three records answer three different questions

Most explanations present them as three layers of one defence. They are not. They are three separate questions, asked about three different parts of the same message.

SPF answers: is this server allowed to send for us. The domain publishes a list of IP addresses and included providers, and the receiver compares the connecting server's address against that list. The detail almost every summary omits: SPF is checked against the SMTP envelope address (MAIL FROM), not against the address a person sees in the From field. The two can differ freely. The specification is RFC 7208.

DKIM answers: was the message altered. The sending server cryptographically signs selected headers and the body and adds a DKIM-Signature header. The receiver fetches the public key from DNS and verifies the signature. DKIM says nothing about who was authorised to send — only that the holder of a key took responsibility and that the signed content has not been touched since. The specification is RFC 6376, which holds Internet Standard status (STD 76).

DMARC answers: what should a receiving server do when no passing SPF or DKIM result aligns with the visible sender. It also does something neither of the others does — it ties the outcome to the domain in the visible From field. It requires that at least one of SPF or DKIM passes and that its domain matches the From domain. That match is called alignment, and it is central to DMARC authentication. Since May 2026 DMARC has been a Standards Track document, RFC 9989, which replaced the informational RFC 7489.

The ten-minute self-check

Run these against your own domain. dig on Linux or macOS, nslookup -type=TXT on Windows. Substitute your domain for example.com.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com

How to read what comes back:

• No v=spf1 record. No SPF policy is published at the queried domain. Check the actual envelope domain used by the sender.
• -all, ~all, ?all, +all. These mean fail, softfail, neutral and pass for otherwise unmatched senders. The receiver decides delivery; softfail does not itself require the spam folder. Avoid +all.
• No record at _dmarc. Check for an inherited organisational-domain policy before concluding there is no DMARC policy.
• p=none. DMARC requests no quarantine or rejection. Aggregate reports require a valid rua destination and reporting receivers. Other filters can still reject mail.
• Subdomains and rollout. Without an overriding subdomain policy, applicable policy is inherited. Missing sp or np alone does not leave a subdomain unprotected. RFC 9989 replaces pct with a testing flag t; check receiver support before changing an established rollout.

DKIM cannot be checked from outside without the selector, and selectors are not enumerable. Take it from a real message you sent: open the source and find s= inside the DKIM-Signature header. Then query dig +short TXT s1._domainkey.example.com, substituting the value of s=.

The last step is the one that changes the conversation. Send a message from your own mail system to a mailbox at a large provider and read the Authentication-Results header (RFC 8601). It records what a stranger's server concluded: spf=pass, dkim=pass, dmarc=pass (p=NONE). A pass on this legitimate message confirms that sending path; it does not test rejection of forged mail.

"We have DMARC" is not an answer

DNS tells you what you published. It does not tell you what happens when somebody tries.

That gap between a declared control and a verified one is the same gap that shows up with MFA, with conditional access and with network segmentation. The record is present, it looks correct, and mail carrying your domain in From still lands in internal mailboxes. Possible causes include policy choices and exceptions: a connector in your own tenant that treats external mail as internal, a trusted-sender list that skips the check, a rule added three years ago for a printer or an accounting package and never removed.

So the interesting question is not "do you have DMARC". It is whether anyone has verified what actually happens when someone tries — from an unauthorised host, with your domain in From, to a mailbox you control. That is a measurement, not a document. Agree the scope and test window first; the result answers something DNS alone cannot.

What no DNS record stops

Three things walk straight through a perfectly configured DMARC policy.

A look-alike domain. The attacker registers example-ltd.com, exarnple.com, or your exact name under a different top-level domain, and publishes their own flawless SPF, DKIM and DMARC on it. Every check passes, because the message really is authentic — for their domain. Cyrillic sharpens this for anyone operating in Bulgaria: а, о, е, р and с have visually identical Latin counterparts, although registry and browser restrictions affect which combinations can be registered and displayed.

The display name. The From field can read Finance – [company] <[email protected]>. DMARC passes cleanly, because the domain it evaluates is gmail.com and that domain is correct. On a phone the visible part is often only the display name; the address is not shown at all.

A compromised mailbox at a real supplier. Everything passes, because it genuinely is them. The reply arrives inside an existing thread, with the right signature, at the right point in the month, and it changes a bank account. This is the variant that costs money, and no DNS record touches it. The control here is procedural: a change of payment details is confirmed over a channel other than the one that requested it.

Separately, SPF, DKIM and DMARC on your domain protect the people who receive mail in your name. They do not protect your staff from other people's domains. That is a different job with a different set of controls, and it borders on how attackers actually get in, where compromised mail remains one of the few entry routes that keeps working.

Why this is a commercial question

Three reasons, each standing without the other two.

First, the protocol records themselves require no separate software licence. The work is identifying every legitimate sender, checking support and testing delivery. Include invoicing, CRM, newsletters and outsourced services. DNS hosting and analysis services may carry their own fees.

Second, a customer's security questionnaire may ask about DMARC. "Do you enforce DMARC at p=quarantine or p=reject" is a yes-or-no question that the buyer can verify from outside, in seconds, without taking your word for it. Very few claims in that document are so cheaply falsified — see also how to answer a customer security questionnaire.

Third, it is now a deliverability question. Since February 2024 Google has required SPF, DKIM and a valid DMARC record from senders of 5,000 or more messages a day to Gmail. From 5 May 2025 Microsoft applied the same threshold to its consumer services (Outlook.com, Hotmail.com, Live.com), rejecting non-compliant mail with 550 5.7.15. Check each receiving provider’s current rules; the bulk-sender threshold is not a guarantee of delivery below it.

What to do first

1. List your legitimate senders. Not from memory. Derive it from your service invoices and from the d= and s= values in the headers of your own outbound mail over the past month. An omitted sender can fail after enforcement is enabled.
2. Run the three queries above and write the answers down. Date them. That is the baseline you will measure against.
3. Turn on reporting before enforcement. Publish v=DMARC1; p=none; rua=mailto:... with an address a person actually reads, and give it a month. The reports will name senders you did not know existed.
4. Tighten in stages and cover subdomains. Move p=none to p=quarantine, then to p=reject, and verify the effective policies for sending, non-sending and non-existent subdomains. Use explicit overrides only where needed.
5. Close the domains that never send mail. For every parked or defensively registered domain, publish v=spf1 -all, v=DMARC1; p=reject; and use a null MX (RFC 7505) only if that domain must not receive mail either. It is the cheapest win available and it is almost always forgotten.
6. Verify instead of assuming. Attempt delivery with your domain in From from an unauthorised host to a mailbox you control, and read what the receiver did with it. Your own domains and your own mailboxes only.

An authenticated message may still request a fraudulent bank-account change. Use the separate payment verification process at the point of approval.

The boundary

DMARC addresses forgery of your own domain, not impersonation in general. Look-alike domains, display names and compromised counterparty mailboxes stay open, and require additional controls such as payment verification, anti-impersonation filtering and domain monitoring.

Enforcement can break legitimate mail. Forwarding and mailing lists break SPF; ARC (RFC 8617) exists for exactly that case but is not honoured everywhere. That is why the moves are staged and the reports are read rather than skipped.

Taking down a fraudulent domain, and registering defensive variants, is a legal and brand matter rather than a technical one. This article is about configuration, not enforcement action.

Email trust work is not by itself DORA or NIS2 compliance — it is one of the technical controls that falls inside their scope. Which of the two applies to you, and whether either does, is a separate question covered in the DORA or NIS2 overview. What an engagement includes and on what terms is set out on the scope and prices page.

If you want the answer measured rather than declared, the Trust Audit runs exactly this check and gives you the result in writing.

Note: this is general information, not legal advice. Applicability depends on the specific entity, its activity, licence, size, group structure and national implementation.

If legitimate mail is landing in spam, use the delivery diagnostic checklist to separate authentication, reputation and sending-path problems.