Your mail server accepts outgoing messages. The queue is moving, other providers receive the email, and nothing appears broken locally.
Then someone sends to Gmail and the message comes back rejected.
That does not necessarily mean Postfix, Exim or the SMTP service has stopped working. The server connected to Gmail and attempted delivery. Gmail then evaluated the sending address, the domain identity, authentication and recent sending behaviour before deciding not to accept the message.
A working mail server and reliable delivery are not the same thing.
Sending successfully does not mean Gmail must accept it
An SMTP server can open a connection, introduce itself correctly and submit a valid message. Gmail still makes its own decision at the receiving side.
For all senders to personal Gmail accounts, Google currently requires SPF or DKIM authentication, valid forward and reverse DNS for the sending address, and TLS. Higher-volume senders must meet additional requirements, including SPF and DKIM together, DMARC and alignment with the visible From domain.
Reputation and sending behaviour also matter. A message can be technically valid and still be delayed, filtered or rejected when Gmail distrusts the IP address, the domain or the traffic pattern.
A migration can leave the old IP behind
Consider a normal mail server migration.
The domains, mailboxes and configuration move to a new VPS. Incoming mail works, users can log in, and Postfix submits outgoing messages without reporting a local error.
However, the SPF record still authorises only the previous server.
The new machine sends the message, but Gmail sees an IP address that the domain has not authorised. From the administrator’s point of view, the migration looks complete. From the receiving server’s point of view, an unknown system has started sending mail for that domain.
The same problem can affect only some hosted domains. The primary domain may have correct DNS while an alias, an application domain or a secondary sender still references the old infrastructure.
The server works. The identity attached to that particular message does not.
Gmail publishes specific SMTP rejection codes for messages that fail SPF or DKIM authentication, so the delivery response often identifies this more clearly than a generic online test.
IPv6 can become the unexpected sender
A server may have working IPv4 and IPv6 connectivity.
The administrator checks the IPv4 address, confirms its PTR record and tests its reputation. Postfix then chooses IPv6 when connecting to Gmail.
If the IPv6 address has no reverse DNS, no matching forward record or incomplete authentication, Gmail evaluates the message using an identity nobody intended to use.
Mail to one provider may leave over IPv4 and arrive normally. Gmail may receive the next message over IPv6 and reject it. The behaviour looks inconsistent until the real outbound address becomes clear.
Google applies its PTR and authentication requirements to the address that actually sends the message, including IPv6, and documents specific SMTP errors when IPv6 does not meet them.
Reverse DNS must describe the actual server
A PTR record is not merely a hostname attached to an IP address.
Suppose the VPS still uses the provider’s generic reverse DNS name while the mail server introduces itself as mail.example.com. The forward DNS for mail.example.com points to the VPS, but the IP reverses to an unrelated provider hostname.
The two directions describe different identities.
Another common mistake is setting the PTR to mail.example.com without ensuring that the hostname resolves back to the same sending IP.
Gmail requires the sending IP to resolve to a hostname through PTR and that hostname to resolve back to the same address. A missing record or a forward-confirmed reverse DNS mismatch can produce a temporary delivery failure.
Changing random DNS records until an online checker turns green is not enough. The hostname, forward DNS, reverse DNS and outbound address must describe the same mail server.
DKIM can exist in DNS and still fail
Seeing a DKIM record in DNS does not prove that current messages carry a valid signature.
The server may sign with a different selector from the one published. A migration may copy the public DNS record but not the matching private key. A hosting panel may generate a new key while the old record remains online.
In every case, the domain appears to have DKIM configured. Gmail still receives a signature it cannot verify.
Multiple domains on one mail server make this easier to miss. One domain signs correctly, another still uses an obsolete selector, and a third sends without a signature because its configuration was never completed.
Testing one successful domain does not validate every sender on the server. Gmail can explicitly reject mail when DKIM authentication fails.
SPF and DKIM can pass while DMARC still fails
This is where authentication becomes less intuitive.
SPF validates the domain used by the SMTP envelope. DKIM validates the domain that signed the message. The recipient usually sees a separate domain in the From header.
Those domains may all be different.
An application might display [email protected] in the From field while using another service domain for the envelope sender. SPF passes for the service domain.
The message may also contain a valid DKIM signature from the provider’s domain rather than example.com.
SPF passed. DKIM passed. Yet neither authenticated identity aligns with the domain visible to the recipient, so DMARC can still fail.
For senders delivering more than 5,000 messages per day to personal Gmail accounts, Google requires the visible From domain to align with either the SPF or DKIM domain. Messages can also be rejected when the sender’s own DMARC policy requires authentication that the message does not satisfy.
This is why three DNS records shown as present do not necessarily explain the delivery result.
Correct DNS does not guarantee a good reputation
A new VPS address does not come with guaranteed trust.
It may have little useful sending history, or its previous use may have damaged its reputation. Gmail can therefore limit messages from a correctly configured server while it evaluates the traffic coming from that address.
An established server can lose trust as well.
One compromised mailbox may suddenly send hundreds of authenticated messages. SPF, DKIM and reverse DNS remain correct, but the behaviour associated with the IP and domain changes.
Legitimate users sharing the same infrastructure can then see their messages delayed, filtered or rejected.
Google states that domain and IP reputation depend on sending behaviour. Its Postmaster Tools also reports authentication, spam rate and delivery errors for mail sent to personal Gmail accounts.
Authentication proves identity. It does not prove that the identified sender behaves responsibly.
Temporary rejection is different from permanent rejection
Gmail may defer a message rather than reject it permanently.
A temporary response tells the sending server to keep the message in its queue and try again later. This can happen because of rate limiting, DNS problems, unusual traffic or low confidence in the sender.
A permanent rejection means retrying the same message without correcting anything is unlikely to help.
That distinction matters.
Treating every delay as a permanent block can lead to unnecessary changes. Ignoring repeated temporary failures is equally dangerous because messages may remain queued for hours before eventually expiring.
Gmail’s published SMTP responses distinguish temporary errors from permanent failures and often point directly towards PTR, authentication, reputation or sending-rate problems.
“Gmail blocks my server” is not a diagnosis. The actual response usually contains the beginning of one.
I would verify the path Gmail actually evaluated
I would not begin by rewriting every DNS record or moving the mail server to another provider.
First, I would establish which IP address delivered the message, which hostname the server presented and what Gmail returned during the SMTP exchange.
Then I would compare the visible sender with the domains authenticated through SPF and DKIM. I would also check whether the problem affects every hosted domain, one specific sender or only messages leaving through IPv6.
Traffic changes matter too.
A sudden increase may come from a compromised mailbox, an abused contact form, a newsletter job or an application repeatedly sending the same notification.
The objective is to understand why Gmail distrusts that specific delivery path. Passing a few isolated online checks does not replace examining the message Gmail actually received.
Need help with Gmail delivery failures?
A mail server can remain fully operational while its messages fail authentication, alignment or reputation checks.
I can inspect the real delivery path, identify why Gmail is rejecting or delaying the messages and correct the relevant mail, DNS or server configuration without changing unrelated settings.