Rebuilding SPF, DKIM and DMARC After a Compromise

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

If your site was hijacked to send spam, one question is worth asking: how was anyone supposed to tell that mail from yours? Email authentication is the answer, and most small business domains have it partly configured, misconfigured, or not at all. Getting it right speeds your recovery and makes the next incident much less damaging.

Why this matters after a hack

When spam goes out carrying your domain, mailbox providers have to decide what to do with it. With no authentication in place, they cannot distinguish it from your genuine mail, so both get treated the same way — which is how a compromise turns into months of your invoices landing in junk folders.

With authentication configured properly, unauthorized mail fails verification and can be rejected outright, while your legitimate mail passes and keeps its standing. The spam still happens, but the collateral damage to your own deliverability is far smaller.

SPF: who is allowed to send

SPF is a DNS record listing the servers permitted to send mail for your domain. A receiving server checks whether the sending server appears in that list and treats mail that fails accordingly.

Two mistakes are extremely common. The first is having more than one SPF record, which is invalid — you must have exactly one, listing every legitimate sender: your hosting server, your mailbox provider, your transactional email service, your marketing platform. The second is forgetting a sender, which quietly breaks mail you did not realize was going out through a different service. Get the complete list first, then write one record covering all of it, and end with a soft fail or hard fail rather than a neutral result that means nothing.

DKIM: proving the message is unaltered

DKIM signs outgoing messages cryptographically. You publish a public key in DNS, your sending service signs with the private half, and receiving servers verify the signature. A valid signature proves the message genuinely came from an authorized sender and was not modified along the way.

Setup is done at the sending service rather than by hand — your mailbox provider or transactional service generates the key pair and tells you the DNS record to publish. Each service that sends for you needs its own key and its own record, which is why domains with several senders end up with several DKIM entries. That is correct and expected, unlike SPF.

DMARC: what to do with failures

DMARC ties the other two together and tells receiving servers what you want done with mail that fails. It also asks them to send you reports about mail claiming to be from your domain, which is the part people undervalue — those reports are how you find out that someone is sending as you.

Start in monitoring mode, which requests reports without affecting delivery, and read them for a few weeks. They will show you every source sending as your domain, including the legitimate ones you forgot about. Once you are confident your genuine senders all pass, tighten the policy to quarantine and eventually to reject. Going straight to reject before you have checked the reports is the fastest way to stop your own mail from being delivered.

The order to do this in

Inventory every legitimate sender first: your website, your mailbox provider, any transactional service, your marketing platform, your accounting or invoicing software, your booking or support system. Missing one is the cause of nearly every self-inflicted deliverability problem.

Then publish one correct SPF record covering all of them, set up DKIM at each sending service, and publish a DMARC record in monitoring mode. Read the reports, fix what fails, then tighten the policy in stages. Do not rush the last step.

What it does and does not fix

It does not clean your site or remove a mailer script, and it does not delist you from anything — those are separate jobs covered in finding the mailer script and email deliverability recovery. It also does not prevent mail being sent through your own authorized server by malware, since that mail authenticates correctly.

What it does is make your legitimate mail verifiable, reduce the reputational blast radius of a compromise, stop other people spoofing your domain from elsewhere, and give you visibility through the reports. That is a substantial return for three DNS records, and it is worth doing whether or not you have just been hacked. If you want the compromise itself dealt with properly first, that is my malware removal service.

Common questions

Can I have two SPF records?

No — that is invalid and causes SPF to fail entirely, which is worse than having no record at all. You must have exactly one SPF record that lists every legitimate sender for your domain. Multiple DKIM records are fine and expected; multiple SPF records are a configuration error.

What DMARC policy should I start with?

Monitoring mode, which requests reports without affecting delivery. Read those reports for a few weeks to discover every source sending as your domain, including legitimate ones you had forgotten. Only then tighten toward quarantine and reject, in stages.

Will this stop my site being used to send spam?

No. If the spam is sent through your own authorized server, it authenticates correctly because it genuinely came from a permitted source. Authentication limits the reputational damage and stops spoofing from elsewhere; removing the mailer script is what stops the sending.

Do I need DKIM if I already have SPF?

Yes. They verify different things — SPF checks the sending server, DKIM checks that the message itself is authentic and unaltered. DMARC depends on at least one of them passing with proper alignment, and having both makes your mail considerably more robust in transit.

What if I do not know all my sending services?

Publish DMARC in monitoring mode and read the reports — they will show you every source sending as your domain, which is usually a more complete list than anyone can produce from memory. Almost every domain turns out to have a sender nobody remembered.