What DMARC does not stop

DMARC answers one question and one only: is the domain I can see in this message's From field the same as the domain that passed SPF or DKIM? If the answer is no, the published policy decides what happens to the message.

That question is narrow, deliberately. The field checked is the Header-From, the part after the @, compared character by character. Anything that is not exactly your domain name falls outside the scope, however close the resemblance.

The standard says so itself, on its fourth page. This is not an implementation shortcoming or a caveat of practice: it is the declared scope of the protocol.

A cousin domain is a real domain name, registered by the fraudster, chosen to resemble yours. They own it. They therefore publish their own SPF, DKIM and DMARC on it, all perfectly valid. Their messages pass every technical check, because they lie about nothing: they really do come from the domain they display.

Your configuration can do nothing about it, for a simple reason: a DNS record only ever speaks about the domain it is published on. You have no authority over a domain you do not own.

The hardest variant is the homoglyph: a character from another alphabet drawn identically. The Cyrillic “а” and the Latin “a” render exactly the same. The resulting domain is not similar, it is visually indistinguishable.

A message's From field holds two things: a free-text display name and an address. Your mail client shows the first in bold and often hides the second. No authentication standard checks the display name, because none could: it is prose.

From: "Sarah Whitfield | Harper Legal" <accounts@unknown-supplier.net>

This message passes DMARC without difficulty: the domain actually used is the fraudster's own, correctly configured. On a phone, where most clients show only the name, the recipient sees “Sarah Whitfield | Harper Legal” and nothing else.

A nastier variant puts your real email address inside the display name. The reader then sees their usual contact, address included, while the effective address stays invisible.

If a fraudster obtains the password to one of your mailboxes, they are no longer impersonating anyone: they are you. Their messages leave your servers, under your records, and your own DKIM signs them. DMARC validates them, as it should.

This is the most expensive scenario, because the fraudster reads first. They learn the names, the amounts, the payment dates, the tone of the exchanges, and then step into an existing conversation at the right moment. No domain protection has any purchase here: the answer is two-factor authentication, sign-in monitoring, and rules for approving payments.

• Forwarding. A forwarded message breaks SPF, because the IP address changes. Only DKIM survives, and only if the message was not modified. Mailing lists that rewrite the subject or append a footer break the signature too. The partial answer is ARC, which not every provider honours.
• Inside the organisation. A message dropped straight into a mailbox by a misconfigured internal server may never be submitted to DMARC evaluation at all.
• Inbound mail. DMARC protects your domain at other people's servers. It does not filter what you receive: that is your mail gateway's job.
• Providers that do not enforce. The great majority of world mail volume is handled by servers that honour DMARC, but not all of it. A small company mail server may simply ignore it.
• The channel. Payment fraud can arrive by telephone, by text message or by post. The target bank account does not change.

None of the above is an argument against DMARC. It is an argument against the idea that DMARC is sufficient. Exact spoofing remains the cheapest and most-used technique precisely because it requires no domain purchase, no patience and no stolen password. Removing it forces the fraudster onto slower, costlier and far more visible methods.

There is a second, less-discussed reason: a domain at p=reject sends back daily reports. A campaign mounted against you becomes visible within days, before a client complains. It is the only measure in this file that warns you.

1. Monitoring of lookalike domain registrations through certificate transparency logs. A cousin domain spotted at creation is a cousin domain you can report before it is used.
2. An internal rule for changes of bank details: always call back on the supplier's known number, never the one given in the message.
3. Two-factor authentication on every mailbox, with no convenience exemption for the directors.
4. Short, concrete awareness training centred on the display name and the cousin domain, since those are exactly the two cases the technical controls let through.

The order matters: the first two cost a few hours and cover the larger part of what DMARC leaves open.