A customer sees the company name in the From field and makes a decision within seconds. SPF, DKIM, and DMARC help a recipient assess whether a message using the company’s domain passed agreed checks. They do not confirm that an invoice is genuine, the sender is honest, or the content is safe.
This matters in AI voice invoice fraud: correct DMARC will not stop a message sent from a lookalike domain, a compromised real mailbox, or a legitimate platform abused by a criminal. It protects a specific domain from some forms of spoofing, not the payment approval process.
Three mechanisms, three different questions
SPF publishes in DNS which servers may send mail for the domain used in the technical return path. It helps a recipient evaluate the sending path. It does not sign content, does not verify the visible From field, and can break when mail is forwarded.
DKIM signs selected headers and the body using a domain’s key. A recipient can check whether the signature matches and whether signed parts changed in transit. A valid signature does not say that the author is honest; it says that the operator of the signing domain signed this form of the message.
DMARC compares the visible From domain with the domain that passed SPF or DKIM. A message passes DMARC when SPF or DKIM both authenticates successfully and aligns with the visible From domain. The published policy applies when neither path meets both conditions. DMARC also provides reports about systems sending with the domain.
SPF and DKIM can pass while DMARC still fails if their domains do not align with the visible From domain. That is not a DMARC defect; it is the question DMARC is designed to answer.
Reports first, enforcement later
A sensible rollout starts with an inventory of every legitimate source: primary email, invoicing, CRM, newsletters, forms, helpdesk, and devices sending alerts. Then:
- correct SPF and enable DKIM signing at each sender
- publish DMARC with the monitoring policy
p=noneand an aggregate-report address - observe a full business cycle, including monthly sends and campaigns
- fix legitimate sources instead of adding broad exceptions
- move in stages to
quarantine, thenreject, when the data supports it
p=none does not block spoofing. It is a data-collection stage. Moving to p=reject too early can reject genuine invoices or notices that were missing from the inventory.
Reading an aggregate report
The XML report gives message counts grouped primarily by source IP and policy-evaluation result; it also includes SPF and DKIM domains and results. It is not a mailbox copy and does not prove that every source IP is hostile.
For each significant source, answer:
- is it a known company provider
- which domain passed SPF
- which selector and domain passed DKIM
- whether either domain aligns with the visible From domain
- how many messages the result covers
- whether the recipient applied the published policy or a local override
The trend and the source owner matter more than one red row. A new legitimate source without an owner is an operational problem even if delivery still works.
Common mistakes
- more than one SPF record at the same name
- too many DNS lookups through chains of
include - stale sources left after changing providers
- DKIM enabled for a domain that differs from the visible From domain
- a compromised, incorrectly published, overused, or prematurely removed DKIM key
- reports delivered to a mailbox nobody reviews
- moving to
rejectwithout checking periodic systems - no policy for unused subdomains and company-owned lookalike domains
DNS changes take time to propagate and affect mail delivery. Each change needs an owner, rollback plan, and tests through several real sending paths. MFA, account protection, a bank-detail change procedure, and second-channel payment confirmation remain necessary. SPF, DKIM, and DMARC make some spoofing harder; they do not end phishing.