What Is DMARC? Protect Your Brand from Forged Email
A customer opens an invoice that uses your name. A finance lead gets a wire request that uses your owner’s name. The domain in the From line is the part people trust, and it is also the part a stranger can type without your permission. The payment is only the first loss. The next real message from your company is the one the customer hesitates to open.
Your mail can be working. Your team can be sending normally. Someone else can still send a message that uses your domain, and the mailbox on the other end has to decide what to do with it. That decision is not made inside your office. It is made by the service that received the message, using instructions you did or did not publish.
What Email Authentication Actually Checks
Email authentication is a set of checks a receiving mailbox runs before deciding whether a message deserves the reader’s trust. Three questions matter to a business.
- First, whether the server that sent the message was allowed to send for that domain. That check is Sender Policy Framework (SPF). You publish a list of services that may send on your behalf: your own mail host, a marketing platform, a billing system, a support desk.
- The second is whether the message carries a seal that only the domain’s owner could apply. That seal is DomainKeys Identified Mail (DKIM). A valid seal survives a forward because it travels with the message rather than depending on which server handed it off last.
- The third is the question people actually care about. Does the domain that passed those checks match the domain the reader sees in the From line? A message can pass the first two checks for a completely different domain and still display your name. Domain-based Message Authentication, Reporting and Conformance (DMARC) is the instruction that closes that gap.
Those checks are not a filter you install on a laptop. They are public notes in the Domain Name System (DNS), read by the mailbox provider that received the message.
Where SPF Stops Short
SPF is useful, and it is not enough to protect the name your customers see.
It authorizes a path, not a promise. SPF says which servers may send for a domain. It does not, by itself, require that domain to be the one printed in the From line. A phishing message can pass SPF for the attacker’s domain, or a lookalike, and still show your brand where the reader looks first.
It breaks when the path changes. A customer who forwards your newsletter to a colleague, or a mailing list that resends a message, puts a new server in the delivery path. That server was not on your list, so a real message can fail SPF even though you sent it. A business that relies on SPF alone then faces a poor choice: loosen the rule until it protects nothing, or keep a rule that punishes legitimate forwards.
It runs out of room. SPF can name only a limited set of sending services before the check fails for every message. A company that adds a marketing tool, a partner portal, a payroll notice, and an events platform can cross that line without writing anything wrong. The record becomes too long for the check to finish, and receivers treat the result as a failure.
It does not tell anyone what to do next. An SPF failure can be ignored. Nothing in SPF says to deliver the message, file it as spam, or refuse it. Nothing in SPF sends the business a readable account of who tried to use the domain. You can be impersonated for months and have no summary to look at.
What DMARC Adds for the Business
DMARC sits on top of SPF and DKIM. It asks the receiver to compare the domain that authenticated with the domain in the visible From address. When those domains agree, the message is aligned. When they don’t, the message fails the check that protects your brand, even if another domain passes its own technical test.
You publish one choice for that failure. A monitor choice asks the receiver to deliver the message and send you a report. Nothing is blocked. This is how a business finds every system that already sends as its domain, including the ones nobody wrote down. A quarantine choice asks the receiver to treat a failing message as spam. The reader might still find it in a junk folder. It does not land in the inbox as if it were ordinary mail from you. A reject choice asks the receiver to refuse the message. A phishing email that forges your From address should not arrive at all.
You can apply the stricter choice to a portion of failing messages first. That lets a business watch the effect before quarantining or refusing every failure. The calm sequence is to monitor, confirm that real mail aligns, then tighten. Subdomains can follow the same choice or a different one. A company that sends customer mail from the main domain and lets a campaign tool use a subdomain can say so, instead of discovering the gap after a fake message does.
DMARC is a request you publish for other mail systems to follow. It does not scan the inbox inside your building. Google, Outlook, and Yahoo Mail are examples of providers that read the instruction when a message arrives for one of their customers. If you have not published an instruction, those providers have nothing from you to apply, and a forged From address can still be delivered.
How a Receiver Uses Your Instruction
Picture a single message arriving at a mailbox provider. The provider looks for your DMARC instruction. No instruction means no request to compare domains, and no request to report what happened.
When an instruction is present, the provider checks alignment. Your own invoice, sent by a service you authorized and sealed, should align. The reader still depends on the provider’s ordinary filters for spam and relevance. Alignment means the domain was used by a sender you allowed. It is not a coupon for the inbox.
A message that fails alignment is handled under the choice you published. Monitor means you learn about it and the reader may still see it. Quarantine and reject ask the provider to keep a forgery out of the inbox.
You also name where the daily summary should go. That summary is an aggregate report, the RUA report. It lists who sent mail using your domain, which messages aligned, and which did not. A second, optional address can request a copy of an individual failure (the RUF report). Many providers send few of those individual copies, or none. The daily summary is the report a business should plan to read.
The Path One Message Takes
The same steps apply to a real message and to a fake one. The fork is alignment, and the choice you published.
- Someone sends a message with your domain in the From address. It might be your billing system. It might be a person building a phishing email that copies your logo and your tone.
- A receiving service such as Google, Outlook, or Yahoo Mail accepts the message for inspection. The reader has not seen it yet.
- The receiver checks SPF and DKIM. It asks whether the sending path was authorized, and whether a valid seal is present, for whatever domain those checks name.
- DMARC compares that authenticated domain with the domain the reader would see. A match means the message is aligned with your brand. A mismatch means the visible From address was not backed by your domain.
- An aligned message continues on the provider’s normal path. Your reputation and the content still matter. What you have gained is a fair claim: this message was allowed to use your domain.
- A message that does not align follows your published choice. If you are only monitoring, the phishing message can still reach the inbox, and it will show up in the report. If you chose quarantine, the provider is asked to treat it as spam. If you chose reject, the provider is asked to refuse it, so the forged message does not arrive.
- The outcome is added to the daily summary sent to the address you named. You can see a vendor you forgot to authorize, and you can see an attempt to impersonate the company. Both are business facts, not just mail-server facts.
That’s why DMARC is a management decision. The technical checks already existed. The missing piece was an instruction that ties those checks to the address a person reads, and a report that tells you whether the instruction matches real life.
A Sensible Order for a Business
Start by publishing a monitor instruction and a report address before you block anything. Read the summaries. Every legitimate sender should show up there: payroll, support, an agency, a store, an event invitation. Authorize the ones that are yours. Treat the ones that aren’t yours as a reason to tighten.
Move to quarantine when the reports show that your real mail aligns and the failures are the ones you want kept out of the inbox. Move to reject when you are willing to have forgeries refused rather than filed as spam. Skipping the reports and jumping straight to reject is how a business blocks its own invoices.
When you are ready to publish or adjust that instruction, use the builder. When the summaries arrive, use the viewer to read them in plain language instead of the raw report file.
