From audit to working SPF, DKIM and DMARC in one working day, without interrupting the mail

A mail server for four company domains signed nothing, published no DMARC policy and was rejected by Microsoft. Our engineers audited it, piloted the change on one domain and rolled it out in batches. The result: all three checks pass at Gmail, the Microsoft block was lifted, and the users noticed nothing.

Book an intro call The email deliverability service

1 working day from audit to roll-out
Zero downtime
SPF, DKIM and DMARC pass at Gmail

A mail server for four domains of small companies, with the DNS spread over three operators

Challenge

The server handled four domains, but none of them signed its mail with DKIM or published a DMARC policy, and one domain had no SPF record at all. Since the large mailbox providers tightened their rules for senders, such mail lands in spam more often or is rejected. On top of that, mail to Microsoft mailboxes came back with the error 550 5.7.1 (S3150).

The DNS of the four domains was spread over three operators, so every change meant several panels and a separate check for each.

Solution

First an audit: the configuration of Postfix, Dovecot and amavis, the public DNS of all domains and the logs of the last days. Then a plan in stages, by priority: DKIM, DMARC and the Microsoft block first, hardening and monitoring after.

One domain served as the pilot, the rest followed in batches grouped by DNS operator. Every DNS record was checked from the outside, on both authoritative servers and on public resolvers, before a domain started signing. Each step had a copy of the configuration and a rollback procedure, and Postfix kept delivering even if signing had failed.

Results

SPF: 4 of 4 domains, plus a record for the server's HELO name
DKIM and DMARC: 4 of 4 domains sign with DKIM and publish DMARC
Check at Gmail: SPF, DKIM and DMARC pass
Microsoft block: Lifted 1 hour 18 minutes after the first message to support
Downtime during the roll-out: None
From audit to roll-out: 1 working day

How we worked

Audit without changes

The configuration of Postfix, Dovecot and amavis, the DNS records of all domains and the logs of the last days. Nothing on the server was changed at this stage.
Plan in stages

First what affects deliverability most: DKIM, DMARC and the Microsoft block. Hardening and monitoring afterwards.
Pilot on one domain

Only then the other domains, in batches grouped by DNS operator.
Every record checked from the outside

Both authoritative name servers and public resolvers, the RSA key, the tags, the TTL, and whether keys repeated between domains.
A gate before signing

A domain joined the signing table only after its key had passed the test. A domain with a wrong or missing record was skipped without stopping the others.
Safe changes

A copy of the configuration and a rollback procedure before every step. Postfix accepted mail even if the signing service had failed.

Challenges we overcame

Most of the time went into things that looked right but were wrong, or looked wrong but were right.

A diagnostic tool that lied about the PTR record

A lookup of the server's PTR record returned a completely different test host name, which looked like a serious mismatch with the HELO name. The cause was the local resolver on the diagnostic workstation: it answered PTR queries from the host file of the machine. In public DNS the record had been correct all along. From then on every DNS check went directly to the authoritative servers and to a public resolver.

Microsoft said the address was not blocked, and rejected mail anyway

This is the bounce a user received; the addresses and the time stamp are anonymised:

<**************@hotmail.com>: host hotmail-com.olc.protection.outlook.com[x.x.x.x]
said: 550 5.7.1 Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
[Name=Protocol Filter Agent][AGT=PFA][MxId=**************] [**************.eurprd04.prod.outlook.com 2026-03-17T08:14:52.316Z **************] (in reply to MAIL FROM command)

The rejections carried the code S3150, while Microsoft's self-service portal insisted that the IP address was not blocked. S3150 means a block on a range of addresses at the hosting provider, not on a single address, and the portal only handles single addresses. The way out was a ticket with Microsoft's support, escalated with facts: SPF, DKIM and DMARC in all domains, clean public blacklists, low volume, authenticated senders only. The confirmation that the block was lifted came 1 hour 18 minutes after the first message to support. DKIM and DMARC do not remove such a block, because Microsoft rejects the connection before it sees the message; complete authentication makes the escalation far stronger.

The server could have started signing incoming spam

With the signing milter enabled globally, as most guides suggest, mail scanned by amavis would have passed through it a second time on its way back into Postfix. Incoming spam with a forged sender from one of the four domains would then have received a valid DKIM signature of that domain. The milters are therefore switched off on the port amavis hands mail back to and on the public port 25.

One tag in a DKIM record, and the TTL

The key test failed with "unknown hash": the h= tag of a DKIM record takes hash names such as sha256, not the name of the signature algorithm. Receivers that follow the specification would have rejected every signature. The record was corrected before the domain signed anything, and the key test became the condition for enabling signing. Because the record had a TTL of a day, resolvers could have cached the wrong version for 24 hours; for the roll-out the TTL was lowered to one hour.

Bounces need SPF for the server's own name

A non-delivery report has an empty envelope sender, so SPF checks the HELO name of the server instead. Without an SPF record for that name, bounces would fail DMARC once the main domain moves to reject, and outside senders would never learn that their mail did not arrive. One record fixed it.

A laptop asks a local resolver with a cache, whose answer is crossed out, and the authoritative DNS server, marked with an orange tick, which hands over the real record

Before and after

Check	Before	After
SPF	3 of 4 domains, no SPF for the HELO name	4 of 4, plus SPF for the HELO name
DKIM	0 of 4: the server did not sign at all	4 of 4 active
DMARC	0 of 4	4 of 4, p=none with aggregate reports
Result at Gmail	SPF pass only	SPF, DKIM and DMARC pass
Microsoft (Outlook, Hotmail)	Rejections with code S3150	Block lifted 1 hour 18 minutes after the first message to support
Time and downtime	Four domains, three DNS operators	One working day, zero downtime

What we take from it

Missing DKIM and DMARC is a deliverability problem today, not a matter of good practice. The large providers increasingly expect all three mechanisms.
The details take the time: the path of a message through the content filter, the chroot, the tags in the records, the TTL, the bounces and reading numbers in the logs. More than 2,500 log lines about missing TLS turned out to be 36 messages in five days, most of them automatic replies to bulk senders; the TLS requirement stayed.
Several domains at several DNS operators can be done without downtime: audit, pilot, batches, a check from the outside after every step and a rollback plan ready.

The next steps for the operator are written down: analyse the DMARC reports, move to quarantine and then to reject, monitor the reputation of the address and the domains in the sender tools of Microsoft and Google, and a procedure for a new domain in which one script produces the key, the table entries and the DNS values.

The DMARC policy as a staircase: p=none with aggregate reports is reached and framed in orange; p=quarantine with the spam folder and p=reject with a rejected message are the next steps, dashed

Related situations

Emails land in spam

Invoices, quotes or one-time passwords land in spam or come back? Since November 2025 Gmail has enforced its sender rules more strictly, including rejections (As of 2026-10). We check SPF, DKIM, DMARC and reputation and give you a written action list.
Debian upgrade and CentOS replacement

Support for Debian 11 ended on 31 August 2026, and for CentOS 7 on 30 June 2024 (As of 2026-10). We will upgrade your server, or plan and carry out the move to Debian. We also work with Proxmox VE 8 and with physical servers that we move to Proxmox.

More projects

A photo upload app for wedding guests

Wedding guests scan a QR code, open one secret address and upload photos and videos straight from the phone: no app, no account, no login. Files of up to 5 GB land on the client's own disk, and the couple watches the gallery fill up during the party. One evening, no second chance, and phones from six years back.
A spam filter that ran but did not protect

Services up, configuration valid, no errors in the system status. Yet phishing landed in the inboxes while partners' newsletters went to spam. Our engineers measured which detection mechanisms actually fired, repaired the causes, and three months later found and fixed a regression that only showed up hour by hour.