DMARC: who can send email as your domain?

DMARC is a record published in your domain's DNS. It tells your recipients' mailbox providers what to do with an email that claims to come from you but cannot prove it: let it through, send it to spam, or reject it.

It relies on two other checks, SPF and DKIM, and it only protects you if its policy asks for action. It is one of the settings our domain and email audit reads in detail.

SPF, DKIM and DMARC: three checks, three questions

The sender address on an email is free text, like the return address on a letter. Nothing in the sending protocol stops someone from writing to your customers from an address in your name. These three checks let the recipient verify.

SPF lists the servers allowed to send email for your domain. A message sent from any other server fails.
DKIM signs each message with a key that only your sending service holds; the public key that verifies the signature is published in your DNS (RFC 6376). A message altered in transit, or signed by someone else, fails.
DMARC ties both to the domain the recipient sees in the "From" field. It sets the policy to apply when neither SPF nor DKIM confirms that domain, and it can ask for reports on mail sent in your name.

Since May 2026, DMARC has been defined by RFC 9989, published by the IETF as a standard, replacing the 2015 version. The principles described here are unchanged.

None, quarantine, reject: what each policy asks for

The policy is the "p" tag in the record. It only applies to messages that fail: your legitimate, properly authenticated email is not affected.

none: do nothing special. The spoofed message is handled like any other. This policy is for collecting reports before tightening, and it protects nothing while it stays in place.
quarantine: treat the message as suspicious, usually by sending it to spam. The spoofed message still arrives, just not in the inbox.
reject: refuse the message. The recipient never gets it.

A record that contains only "v=DMARC1", with no policy and no report address, is ignored by mailbox providers. It looks like it is in place, and it does nothing.

What Gmail, Yahoo and Outlook require from senders

Since February 2024, Google and Yahoo have required every sender to use at least SPF or DKIM. Senders of more than 5,000 messages a day to their users must also publish SPF and DKIM, plus a DMARC record whose domain matches the "From" domain. Microsoft set similar rules for Outlook.com in May 2025.

These rules accept the none policy. A domain can meet them, get its email delivered, and still ask for nothing against spoofing. Being accepted by Gmail and being protected are two different questions.

What we find on the sites we audit

10%receive email on their domain with no SPF, or no valid DMARC

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

What the audit looks at

The audit reads what your domain publishes in DNS, in this order:

Whether the domain receives email. A domain that declares mail servers is a domain that can be spoofed convincingly.
Whether an SPF record is published.
Whether the DMARC record is missing, invalid or present. A record reduced to "v=DMARC1" counts as missing, because mailbox providers ignore it.
The policy requested. None is scored as no protection, quarantine as partial protection, reject as full protection.

DKIM is not part of the score. Its key is published under a name chosen by the sending service, the selector, which cannot be known from the outside: not finding it does not prove it is missing.

The same pillar reads your domain's expiration date. The guide on domain expiration explains why it matters for email as much as for the website.

What is quick to fix, and what takes a project

Publishing SPF, then a DMARC record set to none that asks for reports, is quick for whoever manages your DNS. It does not protect you yet, but the reports start arriving: they show which services send email in your name.

Moving to quarantine and then reject takes an inventory. Your newsletter, invoicing, website forms and CRM often send under your domain. Each one has to be authenticated before the policy is tightened, or your own email ends up in spam or rejected.

What this check doesn't tell you

We read the records your domain publishes. DKIM cannot be verified without knowing the selector, and we do not see DMARC reports, which only reach the address you set.

How well your email is actually delivered also depends on its content and on the reputation of your sending servers. The report says what is published, not what your recipients receive.

By Quentin Mathis, Z29K · updated September 28, 2026