Most discussions of email security start and end with three protocols: SPF, DKIM, and DMARC. They matter, and many organizations still haven’t finished deploying them. But they answer one question: did this message come from a system the domain owner authorized? When an attacker gets hold of one of your applications’ ability to send email, the answer is yes. The message goes out from your infrastructure, under your domain, with every authentication check passing.
This article explains what the three protocols check, why mail sent by a compromised or misused application gets through all of them, and which controls you can add by routing application email through a relay you own.
What SPF, DKIM, and DMARC actually check
Each protocol authenticates a different part of the sending path:
- SPF (Sender Policy Framework) lets a domain owner publish, in the Domain Name System (DNS),
which hosts are authorized to use the domain in two
identities a sending server presents during the Simple Mail Transfer Protocol (SMTP) exchange:
HELO(the server’s own name) andMAIL FROM(the envelope sender, where bounces go). - DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. In the words of its specification, it lets the organization that owns the signing domain “claim some responsibility for a message”, and lets the receiver confirm the signed parts weren’t changed in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two to the
domain in the visible
Fromaddress and tells receivers how the domain owner views mail that fails. Under its current specification, published in May 2026, the policy can bep=none(the domain owner “offers no expression of preference”),p=quarantine(the owner considers failing mail suspicious), orp=reject(the owner considers every failure a clear sign the use of the domain isn’t valid). Aggregate reports, defined in the companion RFC 9990, show the domain owner which sources are sending mail as the domain.
Getting these right is still a work in progress for many domains. Adaptive Security’s email
security risk assessment
guide lists the common
mistakes: SPF records that exceed the 10-DNS-lookup limit, DKIM keys shorter than 1,024 bits or
never rotated, and DMARC left at p=none, which monitors without enforcing. These have
consequences written into the standards. If evaluating an SPF record takes more than 10 terms that
cause DNS queries (the include, a,
mx, ptr, and exists mechanisms and the redirect modifier), the specification requires a
permanent error (permerror). DKIM signers must use RSA signing keys of at least 1,024 bits and
should use at least 2,048, and verifiers must treat
signatures from smaller keys as invalid.
Adoption numbers show how far there is to go. The EasyDMARC 2025 DMARC Adoption
Report, which examined the top
1.8 million email domains, found DMARC adoption rose from 27.2% to 47.7% between 2023 and 2025. But
508,269 of those domains use the monitoring-only p=none, while 350,513 enforce p=quarantine or
p=reject. As SecurityBrief reported from the
same study,
only 7.7% of the domains use the strictest policy, p=reject.
If your domain isn’t at enforcement yet, finish that work. Then look at the threat these protocols were never designed to address.
The call is coming from inside the house
SPF, DKIM, and DMARC are authentication: they confirm who is sending. They are not authorization for any individual message: nothing in them asks whether this message, to these recipients, with this content, is something your organization intended to send. The DMARC specification linked above says so directly. Its mechanisms “only validate the usage of a DNS domain in an email message. They do not validate the local-part of any email address identifier found in that message, nor do such validations carry an explicit or implicit value assertion about that message or about the Domain Owner.” It also states: “A DMARC pass for a message indicates only that the use of the Author Domain has been validated for that message as authorized by the Domain Owner.”
Every application that sends email is, by design, an authorized sender. Its mail server or email
provider is in your SPF record, its messages carry your DKIM signature, and its From address
aligns with your domain. An attacker who controls that application’s sending capability inherits
all of it. There are several ways to get there, covered in more detail in Email Delivery
Introduces Security Risk Exposure:
a leaked provider application programming interface (API) key, a malicious package in the app’s
dependencies, a compromised host, or a bug that lets a user control what the app sends.
That last one needs no stolen credentials at all. In November 2021, the FBI’s own domain sent
tens of thousands of hoax emails
from [email protected]. The FBI attributed it to a software misconfiguration in its Law Enforcement
Enterprise Portal. The self-described attacker, “Pompompurin,” told KrebsOnSecurity that the
portal’s public account registration flow let the browser supply the email’s subject and body, so
he replaced them and scripted the sends. KrebsOnSecurity’s review of the message headers showed the
mail really had come from the FBI’s own internet address. No spoofing
was involved, so there was nothing for sender authentication to catch.
Relays can be the weak point, too. In 2024, an attacker abused a permissive relay configuration at Proofpoint to send spoofed messages as Proofpoint customers including Best Buy, IBM, Nike, and Walt Disney. As The Hacker News reported, the campaign averaged three million emails a day, peaking at 14 million, and the messages went out with authenticated SPF and DKIM signatures. The relays accepted mail from any Microsoft 365 tenant instead of only the customer’s own; Proofpoint’s fix let customers specify which tenants may relay, denying all others by default.
This kind of abuse is worse than ordinary spoofing in a few ways:
- Your enforcement works for the attacker. Moving DMARC to
p=rejectblocks forgeries of your domain. Mail from your own authorized application isn’t a forgery, so it’s delivered, and with your domain’s reputation behind it. - Recipients have been taught to trust it. Security awareness training tells people to check the sender. Here, the sender is real.
- Your DMARC reports look clean. Aggregate reports help you find unauthorized sources using your domain. Abuse through an authorized source shows up as passing mail from a source you expect.
What an email relay lets you enforce
The protocols can’t judge individual messages, so something else has to. If every application hands its mail to an internal relay or outbox server, rather than talking to an email provider directly, that relay acts as a proxy for your outgoing email and becomes a single point of enforcement for what applications are allowed to send. The two controls below are the place to start, followed by others the same position makes possible.
Log every message
Record which application sent each message, when, from which address, to whom, with what subject, and what happened to it (delivered, bounced, or marked as spam). With that record, observability for email stops depending on each team’s logging habits and each provider’s dashboard. You can detect abuse while it’s happening and, after an incident, answer the questions that matter: which app, which messages, which recipients, and since when.
Logs that hold message content can contain password reset links and other secrets, so decide what to keep, protect access to it, and set a retention period.
Restrict From addresses to a known set
Your password reset flow needs to send from something like donotreply@ or security@. It never
needs to send from ceo.name@ or accounts-payable@. Because DMARC doesn’t authenticate the part
of the address before the @, both pass DMARC when sent from an authorized source. The relay can refuse any From address, display name, or Reply-To that isn’t on the
sending application’s allowlist, which takes executive impersonation off the table for that app.
Give each application its own identity
Issue each application its own credentials for the relay, and attach the policy to that identity:
which From addresses it may use, which recipients it may reach, and how much it may send. When
one app is compromised, you can revoke or pause its access at the relay without touching any other
application, and without rotating the provider keys every other app depends on.
Keep provider keys out of applications
Only the relay holds the email provider’s API keys or SMTP credentials. A leaked .env file or a
malicious package in an application’s build then exposes, at most, that application’s relay
credentials, which are limited by everything else on this list. They can’t be used to send
arbitrary mail as your domain directly through the provider.
Limit who can receive mail
Many applications only ever email a known set of people. An internal tool may only need to reach your own domain. A customer-facing app may only need to email the address on the account that triggered the message, one recipient at a time. The relay can enforce rules like these, such as allowed recipient domains or a maximum number of recipients per message, so a compromised app can’t send to a purchased list.
Rate-limit and alert on unusual volume
Each application has a normal sending pattern. Per-application rate limits cap how much damage a compromised app can do before someone notices, and alerts on volume spikes, new recipient domains, or rising bounce and complaint rates turn the log into early detection. Volume matters to your provider, too: a burst of abusive mail can hurt your domain’s sending reputation and push legitimate mail from every system into spam folders.
Constrain message content
The FBI incident worked because the application accepted a free-form subject and body from the client. A relay can require applications to send a template name and parameters instead of arbitrary content, so the wording of a password reset email is fixed and only the link and name change. Where free-form content is necessary, the relay can check it, for example by allowing links only to your own domains.
Hold suspicious mail for review
Not every rule needs to be a hard block. A relay can quarantine messages that trip a rule, such as an unfamiliar recipient domain, an unusual volume, or a link to an unknown host, and release them after review. That keeps a false positive from breaking a business process while still stopping the message before it reaches the recipient.
Secure the relay itself
A relay concentrates both trust and risk, as the Proofpoint campaign shows. It should accept mail only from the applications you’ve registered, with their own credentials, over your internal network, and deny everything else by default. Treat its configuration, logs, and credentials with the same care as any other system that can speak for your organization.
OutboxServer is one example of this kind of relay: a self-hosted service that applications call to send transactional email, holding the provider credentials, applying your sending policies, and recording what each application sent. The controls above apply whichever relay you use.
Add application email to your assessment
A typical email security assessment checks SPF syntax, DKIM signatures, and DMARC reports. Add these questions about the applications that send as your domain:
- Which applications send email as your domain, and through which providers?
- Which
Fromaddresses can each of them use, and what stops them from using others? - Can you list every message a given application sent last week, and to whom?
- Where are the provider credentials, and how many copies of them exist?
- If one application started sending phishing right now, how would you find out, and how quickly could you stop it without stopping the others?
Bottom line
SPF, DKIM, and DMARC are necessary, and you should get them to enforcement. But they prove that a message came from a system you authorized, not that you meant to send it. Every application with the ability to send email can send it as your organization, with full authentication and full trust. Routing that email through a relay you own gives you the record of what was sent and the authority to decide what each application may send.