DMARC: questions about mail sending and mail receiving

DMARC (Domain-based Message Authentication, Reporting, and Conformance) answers one question for every message: is the domain in the From line actually responsible for this mail? It matters on both sides of the exchange. As a sender, DMARC is how you stop other people sending as your domain. As a receiver, it is how your mail system decides what to do with mail that fails that test. This article answers the questions that come up on each side.

Sender authentication and receiver authentication are different jobs

The sender is the organization whose domain appears in the From line. The receiver is the mail system that accepts and files the message. Authentication is a conversation between the two: the sender publishes DNS records that say which mail is legitimate, and the receiver checks incoming messages against those records. If you only remember one thing, make it this: the sender sets the policy, and the receiver enforces it.

Which address does DMARC actually check?

Every message carries two sender addresses. The envelope sender (the return path) is used by mail servers to route bounces; recipients never see it. The header From is the address people read in their mail client. Spoofing works because the two can differ freely, and older checks only looked at the envelope.

DMARC closes that gap by checking the address people actually see. A message passes DMARC only when SPF or DKIM passes and the domain that passed aligns with the header From domain. That alignment rule is the whole point: an attacker can pass SPF for a domain they own, but they cannot align it with yours.

The parts of the sending system

Envelope and message structure

The envelope carries routing information (the return path and the destination address). The message carries the headers and content, including the From line the recipient reads. SPF checks the envelope; DKIM signs the message; DMARC ties both back to the visible From domain.

SPF (Sender Policy Framework)

An SPF record lists the servers allowed to send mail for a domain. When a message arrives, the receiver checks whether the sending server's IP is on that list. SPF alone does not stop spoofing of the visible From address, because it checks the envelope sender. It becomes useful against spoofing when DMARC requires it to align with the From domain.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC adds two things SPF and DKIM lack on their own: alignment with the visible From domain, and a published policy that tells receivers what to do when a message fails (p=none to monitor, p=quarantine to junk, p=reject to refuse). It also asks receivers to send aggregate reports, which show the domain owner every source sending as their domain, authorized or not.

What senders get from DMARC

Better odds of reaching the inbox

Mailbox providers treat authenticated mail as accountable mail: they know who is responsible for it, so they can score it on its own reputation instead of guessing. Gmail and Yahoo now require DMARC from bulk senders outright. Authentication supports deliverability; no record guarantees inbox placement, because the receiving provider makes the final call.

Forgery stops working

With a policy at p=quarantine or p=reject, mail that fails authentication gets junked or refused by receivers that honor your policy. A criminal can still send mail claiming to be you, but the message arrives pre-flagged or not at all. At p=none, nothing is blocked; monitoring is the means, enforcement is the protection.

You can see who is sending as you

DMARC aggregate reports list every source sending under your domain: your mail platform, your CRM, the invoicing tool nobody documented, and any forgers. That inventory is what makes it safe to move to enforcement, because you fix the legitimate senders before you tell the world to reject the rest.

What receivers get from DMARC

Fewer phishing messages delivered

A receiver that enforces DMARC drops or junks messages that fail a sending domain's published policy. Users see fewer messages that impersonate banks, vendors, and their own colleagues, because the forged From lines that make those attacks convincing stop surviving delivery.

One less path for ransomware

Many ransomware campaigns start with a forged email that looks internal or familiar. Enforcing sender policies removes that specific disguise. DMARC does not scan attachments or links; it narrows the front door those payloads walk through.

An inbox people can trust more

When forged mail stops arriving, the From line starts meaning something again. That benefits every legitimate sender in the ecosystem, which is why the large mailbox providers push enforcement.

A short DMARC action plan

Make sure every third-party service that sends for you is in your SPF record
Publish one SPF record and one DMARC record per domain, never duplicates
Move to DMARC enforcement in stages, using your reports to confirm legitimate mail passes before you tighten the policy
Watch your sender reputation: rising spam complaints will hurt delivery even with perfect records

The order matters. Enforcement without the sender inventory breaks legitimate mail, which is the failure that gives DMARC projects a bad name; the reports exist so you never have to guess.

Where Palisade fits

Getting from a bare record to p=reject means reading the reports, finding every legitimate sender, and fixing each one's authentication before the policy tightens. Palisade's agent does that work: it reads your DMARC reports, identifies every source, drafts each fix, and proposes the next policy step, with you approving before anything changes. Start by checking where your domain stands with the free Email Security Score.