Why does Gmail return 550-5.7.1 even when SPF, DKIM, and DMARC pass?

Because authentication is only part of Gmail's evaluation. Gmail also considers IP and domain reputation, sending behavior, user complaints, and the structure of the individual message.

Will changing the IP address fix Gmail 550-5.7.1?

Only if the problem is actually tied to the outbound IP reputation. If the domain, a specific mail flow, or ongoing spam activity is responsible, changing the IP does not remove the root cause.

Why does Gmail block mail when the IP is not listed in any blacklist?

Public DNSBLs and Gmail's internal reputation system are separate. A clean Spamhaus or other blacklist result does not mean Gmail considers the IP or domain reputable.

Can a missing PTR record cause Gmail 550-5.7.1?

Yes. Reverse DNS problems can affect Gmail acceptance. Check not only PTR but also forward resolution of the hostname, plus the HELO/EHLO identity of the actual outbound MTA.

How long does Gmail take to restore delivery after spam is stopped?

There is no universal fixed period. Remove the spam source, correct authentication and DNS, then monitor new SMTP responses and available Postmaster Tools data.

What should I check first for Gmail 550-5.7.1: SPF, PTR, or blacklists?

Start with the complete Gmail bounce and identify the actual sender IP and SMTP rejection stage. Then rule out active spam before checking SPF, DKIM, DMARC, PTR, and reputation.

Why does Gmail see IPv6 when the mail server is configured for IPv4?

Postfix can use IPv6 when the protocol is enabled and the remote MX is reachable over IPv6. Check the sender IP in the bounce, inet_protocols, smtp_address_preference, bind settings, IPv6 PTR, and SPF.

Gmail 550-5.7.1 “Likely Unsolicited Mail”: Causes and Troubleshooting

The Gmail 550-5.7.1 "This message is likely unsolicited email" error looks like one specific rejection, so the first reaction is usually straightforward: check SPF, change PTR, or look up the IP in blacklists. The problem is that none of these checks alone is enough. Gmail uses the 5.7.1 code for several policy-related rejections, ranging from poor IP or domain reputation to IPv6 issues, malformed message headers, and authentication problems.

Proper troubleshooting should start not with DNS but with the complete bounce message. You need to determine which IP actually sent the email, what Gmail returned, and at which stage of the SMTP session the rejection occurred. Only then does it make sense to investigate SPF, DKIM, DMARC, PTR, HELO/EHLO, IPv6, reputation, and the message itself.

There is another trap: successful authentication does not automatically mean good deliverability. A server can have valid SPF, DKIM, and PTR records while Gmail still rejects its mail because of sender reputation or sending behavior. The opposite happens as well: an administrator may spend days investigating reputation while the message is actually being sent over an unexpected IPv6 address with no PTR record, or without a DKIM signature at all.

Short troubleshooting path: save the complete Gmail response, identify the actual outbound IP, rule out ongoing spam activity, verify authentication and the server's DNS identity, and only then move on to reputation and the specific mail flow.

What does Gmail 550-5.7.1 “Likely Unsolicited Mail” actually mean?

Gmail 550-5.7.1 means Gmail permanently rejected a specific message for a policy or anti-spam reason, but the code itself does not point to one single fault. This is why searching only for 550 5.7.1 often sends administrators in the wrong direction.

A typical bounce looks roughly like this:

550-5.7.1 Our system has detected that this message is likely unsolicited mail.
550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been blocked.

Gmail also uses the same enhanced status code for other rejections: very low sending IP reputation, very low sending domain reputation, IPv6 sender guideline failures, missing or invalid From:, missing Message-ID:, duplicate headers, and other message-format problems.

Gmail response	What to suspect first	What to check next
Likely unsolicited email	Reputation, authentication, sending behavior	Bounce, DNS, Postmaster Tools, mail flow
Very low reputation of the sending IP address	IP reputation	Outgoing IP, shared IP, sending history
Very low reputation of the sending domain	Domain reputation	Domain, DKIM, DMARC, sending history
Does not meet IPv6 sending guidelines	IPv6, PTR, authentication	AAAA, IPv6 PTR, SPF, DKIM
Missing From / Message-ID / duplicate headers	Message format	Raw source, MIME, RFC 5322 headers

Also look at the first digit of the SMTP code. 550 indicates a permanent rejection of the current delivery attempt. If the log shows 421, 450, 451, or another 4.x.x response instead, that is a temporary deferral and should not be diagnosed as a normal 550 5.7.1 case.

Do not try to guess the cause from the word spam. Copy the entire Gmail response, including the IP, identifier, and the text after said:. 5.7.1 defines the rejection class; the actual diagnostic string tells you which troubleshooting branch to follow next.

How can you tell from the bounce and mail log where Gmail rejected the message?

The complete SMTP log shows not only Gmail's response code but also the point at which delivery failed. This helps separate connection or SMTP envelope problems from a rejection that happened after Gmail evaluated the message.

On a Postfix server, start by finding bounced messages:

grep 'status=bounced' /var/log/mail.log

On another system, the log may be located at /var/log/maillog:

grep 'status=bounced' /var/log/maillog

If Postfix logs through systemd journal:

journalctl -u postfix

Find the Queue ID in the matching entry, then collect the full chain for that message:

grep 'QUEUE_ID' /var/log/mail.log

For Exim, outgoing Gmail deliveries are usually traced through the main log:

grep 'gmail.com' /var/log/exim_mainlog

The exact path depends on the operating system and control panel, so there is no single universal log location. cPanel, DirectAdmin, Plesk, and custom server builds may use different paths and formats.

A typical Postfix entry may look like this:

postfix/smtp[...] ... status=bounced
(host gmail-smtp-in.l.google.com[...] said:
550-5.7.1 ... likely unsolicited mail ...
(in reply to end of DATA command))

The phrase in reply to end of DATA command is useful. It shows that the SMTP session reached the point where the message data had already been transferred and Gmail rejected it afterward. In this situation, randomly changing ports, your own domain's MX record, or an SMTP password usually does not address the real issue.

If rejection happens earlier, the troubleshooting path changes. A failure after MAIL FROM, after RCPT TO, during SMTP AUTH, or during TLS negotiation points to different problems. Do not troubleshoot the bounce based on the email subject. First check what the remote MX actually returned.

Save before making changes: Queue ID, date and time, envelope sender, recipient, outbound IP, Gmail MX, the complete 550-5.7.1 response, and the SMTP stage where the rejection occurred.

Only after that should you move on to DNS. If Gmail does not return an SMTP rejection and the user simply cannot see the message in the mail client, that is a different troubleshooting branch: check the Gmail mail client settings separately.

Do SPF, DKIM, and DMARC actually pass for the rejected message?

Having SPF, DKIM, and DMARC records in DNS does not prove that the specific outgoing message passes those checks. The DNS records may look correct while the application actually sends through another relay, uses a different DKIM selector, or generates a mismatched domain in From:.

This distinction matters for Gmail. Authentication requirements depend on sending volume, and bulk senders are subject to additional requirements. So the goal is not to confirm that three TXT records exist in DNS, but to verify the real authentication result of the specific mail flow.

SPF: does it authorize the actual outbound IP?

SPF must be checked against the IP that Gmail actually saw during the SMTP connection. The IP shown in your VPS control panel and the IP in the Gmail bounce are not always the same.

Check the domain's TXT records:

dig TXT example.com

Then compare SPF with the sender IP from the Gmail rejection. Look at ip4:, ip6:, include:, the real envelope sender, and any external SMTP relay in the delivery path.

A typical situation: an administrator spends an hour checking SPF for the VPS address, but the Gmail bounce shows the address of an external smarthost. The VPS SPF configuration may be perfect, but Gmail is seeing a different server. The reverse scenario also happens: an application used to send through an external SMTP service, then switched to local sendmail after a configuration change.

Another problem is publishing multiple independent v=spf1 records for the same hostname. They cannot simply be placed next to each other as separate allow rules. There should be one valid SPF policy describing the actual sending sources.

DKIM: is the message itself actually signed?

A published DKIM key is useless if the outgoing message is not signed with it or is signed with another selector.

Check the DNS record for the selector:

dig TXT selector._domainkey.example.com

But the next check is more important. Open the raw source of a message that successfully reached a test mailbox and find DKIM-Signature:. Check at least the d= and s= parameters. Then look at Authentication-Results: and confirm that the actual result is dkim=pass.

The control panel can still show everything as green. The DNS selector exists, DKIM status says Enabled, but the raw message contains no DKIM-Signature: header at all. This can happen when normal SMTP mail goes through a signing transport while a PHP application uses a different route. Another case is when DNS still contains the default selector while the MTA has already switched to a newer selector.

DMARC: is the visible From domain aligned with SPF or DKIM?

DMARC does not simply check whether a _dmarc TXT record exists. It checks whether the visible sender domain aligns with a domain that passed SPF or DKIM.

Retrieve the record:

dig TXT _dmarc.example.com

Suppose the recipient sees:

From: Shop <sales@example.com>

But the envelope sender uses another domain, while DKIM uses a third value in d=. SPF and DKIM can both be technically valid while DMARC alignment for example.com still fails.

A useful verification therefore looks like this, not merely “three TXT records exist in DNS”:

spf=pass
dkim=pass
dmarc=pass

Check these results in the headers of a message that was actually accepted or in a suitable diagnostic service.

Mechanism	What to verify	False confidence
SPF	Whether the real sender IP is authorized	“The TXT record exists”
DKIM	Whether the actual message has a valid signature	“The selector is published”
DMARC	Whether alignment with the From domain succeeds	“We have p=none configured”

If you have a confirmed authentication failure here, fix it first. Looking for a “secret Gmail blacklist” while authentication is broken is premature.

Do PTR, hostname, and HELO/EHLO match the outgoing mail server?

An outgoing SMTP server should have a consistent DNS identity: IP, PTR, hostname, and forward DNS should not contradict one another. Checking only whether a PTR record exists is not enough.

Check the PTR record of the outbound IP

For IPv4:

dig -x 203.0.113.10 +short

or:

host 203.0.113.10

Replace the sample address with the IP from the Gmail bounce. A sensible result is a normal fully qualified hostname such as mail.example.com, rather than an empty response or an arbitrary internal hostname that does not exist elsewhere.

PTR is normally controlled by the owner of the IP range, usually the hosting provider or data center. Adding a regular TXT, A, or CNAME record to your domain's DNS zone does not create reverse DNS.

Check PTR and forward DNS in both directions

The check does not end when a PTR record exists. The hostname returned by reverse DNS should resolve back to the appropriate mail infrastructure.

dig A mail.example.com +short
dig AAAA mail.example.com +short

If PTR for 203.0.113.10 returns mail.example.com, but mail.example.com has no A record or resolves to an unrelated address, the DNS identity is inconsistent.

Use this sequence:

take the sender IP directly from the Gmail rejection;
retrieve PTR for that IP;
retrieve A and, where relevant, AAAA for the PTR hostname;
verify that forward DNS points back to the same mail infrastructure;
then compare the SMTP HELO/EHLO identity.

Pay particular attention to AAAA. IPv4 may be configured perfectly while the server chooses IPv6 for the outbound connection. The administrator checks IPv4 PTR, IPv4 SPF, and IPv4 reputation while Gmail is actually seeing another address.

Check the actual HELO/EHLO used by Postfix

myhostname alone does not always tell the whole story. With Postfix, check both parameters:

postconf myhostname smtp_helo_name

myhostname defines the Postfix server hostname. smtp_helo_name controls the name used by the Postfix SMTP client in HELO/EHLO; unless it has been overridden, it normally falls back to myhostname.

DNS can therefore look clean while the MTA configuration still needs attention. For example, PTR points to mail.example.com, mail.example.com resolves to the sender IP, but Postfix still introduces itself as oldhost.example.net after an old migration.

Poor choices for a public SMTP server include localhost, a random internal name such as server.local, or a hostname that does not exist in public DNS.

Sender IP: 203.0.113.10
PTR: mail.example.com
A mail.example.com: 203.0.113.10
EHLO: mail.example.com

This does not mean every value must literally match in every relay architecture. Mail clusters and external relays can use their own hostnames. The chain should simply be explainable: which server connected to Gmail, what name it presented, and which DNS records belong to that server.

PTR is not a Gmail unblock button. Correct reverse DNS fixes one infrastructure problem, but it does not erase poor IP history or fix unwanted sending behavior.

How do you distinguish an IP/domain reputation problem from a DNS issue?

SPF, DKIM, and PTR establish technical legitimacy, but Gmail also evaluates IP and domain reputation. A perfectly configured DNS setup does not guarantee acceptance.

Comparing several independent mail flows quickly shows where to investigate. Instead of changing DNS again, check what happens to other domains and other message types using the same infrastructure.

When should you suspect IP reputation?

Poor IP reputation becomes a stronger hypothesis when different domains using the same outbound address receive similar Gmail rejections. It is especially relevant if the IP recently generated abnormal mail volume, the server was compromised, or the address is shared.

Gmail has explicit rejections referring to very low reputation of the sending IP. But the absence of that exact wording does not rule reputation out: likely unsolicited email is a less specific response.

When should you suspect domain reputation?

If five domains using the same IP continue to deliver successfully to Gmail while a sixth domain is consistently rejected, changing the IP first is not logical. Investigate that domain's history, DKIM/DMARC alignment, message type, and recipient feedback.

The opposite scenario is useful too. An administrator moves the problematic domain to another outbound IP and the rejection pattern barely changes. This does not prove poor domain reputation, but it is a reason to stop treating the original IP as the only hypothesis.

Symptom	More likely cause	What to check next
Several domains on the same IP are rejected similarly	IP or shared SMTP infrastructure	Sender IP, shared relay, Postmaster Tools, queue history
One domain is rejected while others work	Domain reputation, authentication, or a specific mail flow	DKIM/DMARC, message type, complaints, recipients
Only one message template has problems	Headers, content, recipients, sending behavior	Raw source and comparison with a working template
The problem appears only over IPv6	IPv6 PTR, SPF/DKIM, or IPv6 reputation	Actual Postfix route and IPv6 DNS
The issue started after a site or mailbox compromise	Security incident and damaged reputation	Queue ID, SMTP AUTH, PHP/cron, volume history

You can build a simple diagnostic matrix:

domain-a.example / IP1 -> Gmail reject
domain-b.example / IP1 -> Gmail reject
domain-c.example / IP1 -> Gmail reject

This pattern points more strongly toward the shared IP or server infrastructure.

Compare it with:

domain-a.example / IP1 -> Gmail reject
domain-b.example / IP1 -> accepted
domain-c.example / IP1 -> accepted

Here it makes more sense to investigate the first domain instead of buying a new IP for the whole server.

A clean public blacklist result does not mean Gmail considers the sender reputable. Spamhaus, SpamCop, and other DNSBLs are separate systems. “The IP is clean in twenty blacklists” is useful information, but it does not close the investigation.

Is the server sending spam from a compromised mailbox, website, or PHP script?

The site should send only a few order notifications per day, but mailq suddenly shows hundreds of recipients on external domains. At that point, PTR and reputation work become secondary. First determine what is creating the messages and whether unwanted sending is still happening.

The source may be a stolen SMTP password, compromised WordPress installation, web shell, vulnerable form, cron task, PHP script, or incorrectly configured relay. As long as the source is active, deliverability work is pointless: the server keeps generating the same traffic that caused Gmail to distrust it.

Start with the Postfix or Exim queue

For Postfix:

postqueue -p

or:

mailq

For Exim:

exim -bp

A large queue does not automatically prove spam. Legitimate messages can also accumulate after a remote MX outage or network problem. Look at the structure: unexpected senders, random recipients, hundreds of similar messages, repeated destination domains, strange subjects, or a sudden increase in queue size.

Select one suspicious message and record its Queue ID or Exim Message ID. Do not immediately delete the entire queue: preserve some evidence for the investigation first.

How to trace a Postfix Queue ID back to the source

With Postfix, you can inspect a queued message using postcat:

postcat -q QUEUE_ID

Compare:

envelope sender;
recipient;
From:;
Message-ID:;
other application-specific headers;
time the message entered the queue.

Then find the same Queue ID in the mail log:

grep 'QUEUE_ID' /var/log/mail.log

or:

grep 'QUEUE_ID' /var/log/maillog

Now determine how the message entered Postfix. With SMTP AUTH, you can often find the authenticated username near the connection entry, for example in sasl_username:

postfix/smtpd[...] ... sasl_method=PLAIN, sasl_username=user@example.com

If dozens of suspicious messages are associated with the same sasl_username, a stolen mailbox password becomes a strong hypothesis. The first response is to change that password, terminate unknown sessions if the control panel allows it, and check devices or applications that used the old credentials.

Local submission looks different. A message can enter through sendmail or a local process without SMTP AUTH. In that case, local UID, process user, and timestamps become more useful. If the messages are created by the web-server user, investigate PHP, CMS, cron, and web logs instead of the mailbox password.

Practical distinction: sasl_username usually points the investigation toward an SMTP account, while a local UID or web-server user points toward a site, PHP process, or system task. This is not an absolute rule for every configuration, but it is a useful first split.

How to trace the source in Exim

The logic is similar with Exim: take the Message ID from the queue and collect the full history:

grep 'MESSAGE_ID' /var/log/exim_mainlog

Depending on the configuration, the log may show the authenticated sender, authentication data, cwd, local user, and other fields. For messages generated by a PHP script, the working directory may immediately point to the website directory. Do not rely on that as a universal feature, though: available fields depend on the Exim build, hosting panel, and logging configuration.

If the log does not provide a convenient path to the script, correlate the message timestamp with web-server access/error logs, PHP logs, and cron jobs. There is no single magic grep command here. The investigation usually requires correlation between several sources.

What should you do after finding the source?

Deleting the queue without removing the source does not solve the problem. The queue will simply fill again.

If the source is an SMTP account, change the password and check where else it was used. If WordPress or another CMS generates the messages, investigate vulnerable plugins, modified files, unknown administrator accounts, web shells, and suspicious cron jobs. If the problem comes from a contact form, verify that it cannot be abused as a mail relay by supplying arbitrary recipient addresses.

For PHP-generated mail, compare message creation times with web logs and cron jobs. There is no universal command guaranteed to identify the exact PHP file because this depends on what the MTA and hosting panel log.

After removing the source, verify that:

the queue no longer grows abnormally;
unknown SMTP AUTH activity no longer appears;
new spam-like messages are no longer generated;
outbound mail volume returns to the expected level;
similar suspicious messages do not reappear after cleanup.

Only then does it make sense to work on deliverability recovery. You cannot rebuild reputation while the server is still sending unwanted mail.

Could the problem be caused by a shared IP, a new IP, or IPv6?

IPv4 has been checked thoroughly: PTR exists, SPF contains the correct address, and DKIM passes. But the Gmail bounce shows an IPv6 address. In that situation, all previous IPv4 troubleshooting misses the main point because Gmail is communicating with a different sender IP.

On shared hosting, mail may go through a shared relay. After a migration, the outbound route may change. A server with working IPv6 connectivity can also use IPv6 when connecting to Gmail. Always take the address from the actual SMTP session rather than assuming which IP “should” be used.

Compare IPv4 and IPv6 in DNS first

dig A mail.example.com +short
dig AAAA mail.example.com +short

Check reverse DNS for both addresses that may actually be used:

dig -x 203.0.113.10 +short
dig -x 2001:db8::10 +short

Then compare SPF:

v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all

This is only a syntax example, not a record to copy blindly. If the server is not supposed to send over IPv6, do not add ip6: simply to authorize everything. First determine why that route is being used.

Why did Postfix choose IPv6?

DNS only shows which addresses are available. To understand Postfix behavior, check its network-related parameters:

postconf inet_protocols
postconf smtp_address_preference
postconf smtp_bind_address
postconf smtp_bind_address6

inet_protocols shows which IP protocols Postfix is allowed to use. smtp_address_preference affects address preference for outgoing SMTP delivery. smtp_bind_address and smtp_bind_address6 can explicitly bind the SMTP client to a local IPv4 or IPv6 address when configured.

An empty bind parameter is not automatically a fault. In a normal setup, Postfix may let the network stack choose the appropriate local address. What you are looking for is an explicit or forgotten setting that causes the MTA to use an unexpected address.

A revealing scenario looks like this:

AAAA: present
IPv6 PTR: missing
SPF: contains only ip4
inet_protocols: allows IPv6
Gmail bounce: shows IPv6

There is no reason to start changing the subject line or searching another blacklist here. Fix the infrastructure first: either configure IPv6 completely for outbound mail or change the MTA setup so that delivery really uses the intended IPv4 address. The correct option depends on the server architecture.

What changes when you use a shared IP?

With a shared SMTP IP, reputation does not depend only on your domain. If another user generates large amounts of unwanted mail and the provider does not control abuse well, the shared address can suffer.

Your domain can have perfect SPF, DKIM, and DMARC while the IP itself remains under the provider's control. When contacting support, provide the sender IP, exact Gmail rejection, timestamp, Queue ID, and authentication results. “Gmail does not accept our mail” gives support almost nothing to investigate.

What should you consider with a new dedicated IP?

A new IP should not automatically be considered “clean and perfect.” The absence of DNSBL listings does not create Gmail reputation. If a new address immediately starts sending a large volume of identical messages, having no history is not automatically an advantage.

At the same time, there is no need to mystify IP “warming.” A server with a small natural transactional mail flow does not need an artificial schedule of sending messages to itself. The real goal is predictable volume to recipients who expect the mail, correct authentication, and no sudden anomalies.

Quick check: compare the IP from the Gmail rejection with the IPv4/IPv6 addresses covered by SPF, PTR, and MTA configuration. If they differ, you were troubleshooting the wrong route.

Can Gmail reject a message because of its headers, content, or sending pattern?

Yes. If DNS and server reputation look normal, inspect the specific message and how it is sent. A useful clue is when a normal personal message from the same domain is accepted while application notifications or a bulk template are rejected.

Check the message structure, not only the text

In the raw source, inspect:

a valid From:;
a single valid sender address;
Message-ID:;
Date:;
valid MIME structure;
header encoding;
absence of duplicate headers;
reasonable RFC 5322 compliance.

Gmail has separate 550 5.7.1 variants for missing From:, missing Message-ID:, multiple addresses in From:, duplicate headers, and other RFC 5322 violations.

The problem is not always in the MTA. An application or old script may build the message manually and generate a malformed header, duplicate From:, broken MIME boundary, or invalid encoding. The mail server simply sends what it was given.

If one message works and another does not, compare their raw source. That is more useful than randomly rewriting the subject line. If Gmail has already accepted the message but the user cannot find it where expected, check the Gmail filter settings separately.

Check the sending behavior

Correct authentication cannot compensate for sending mail that recipients do not want. Troubleshooting should therefore consider not just the server configuration but also who receives the messages, how often they are sent, and why.

Did sending volume increase sharply?
Was an old or unverified recipient list imported?
Is there valid opt-in for subscription mail?
Does unsubscribe work correctly?
Is a regular web server sending thousands of marketing messages?
Has the user-reported spam rate increased?

Senders that reach roughly 5,000 messages per day to personal Gmail accounts are subject to additional requirements, including SPF and DKIM, DMARC, alignment, and unsubscribe requirements for marketing or subscribed mail. Once a domain is treated as a bulk sender, reducing volume later should not be viewed as an automatic way to return to ordinary-sender requirements.

Keep the spam rate well below 0.3%. A more practical target is below 0.1%, rather than treating 0.29% as an acceptable operating level.

Do not treat “spam words” as the main diagnosis

Lists containing words such as FREE, SALE, CLICK HERE, or “100 words Gmail considers spam” are far too simplistic for this type of investigation. Content can contribute to filtering, but rewriting a few words does not fix poor IP reputation, broken DKIM, or a recipient list full of people who never requested the messages.

A controlled comparison is more useful:

the same server with two different message types;
the same domain with transactional and marketing flows;
the same sender with a correctly formatted simple message;
raw headers from an accepted message versus a rejected one.

If only one specific flow is blocked, the bottleneck no longer needs to be searched for across the entire server.

What does Google Postmaster Tools show, and why is a blacklist check not enough?

An administrator brings a blacklist report: Spamhaus — clean, SpamCop — clean, and dozens of other DNSBL checks are green. Gmail still rejects mail for reputation reasons. There is no contradiction. Public blacklists and Gmail's internal reputation system are separate systems.

Spamhaus: clean
SpamCop: clean
Other DNSBL: clean

does not mean:

Gmail reputation: good

Postmaster Tools provides another source of evidence. It can help correlate spam rate, reputation, authentication, and delivery errors with what appears in SMTP logs. Small senders may not see all data, and improvements after changes are not necessarily reflected immediately.

How should you interpret Postmaster Tools data?

What you see	How to interpret it	What to check next
Authentication is lower than expected	Part of the real mail flow fails SPF, DKIM, or DMARC	Separate mail flows; check sender IP, DKIM-Signature, and alignment
IP reputation is poor while domain reputation looks better	The sender IP or shared infrastructure becomes more suspicious	Other domains on the IP, spam history, shared relay
Domain reputation is poor while IP reputation is normal	The problem may be tied to the domain and its mail flow	DMARC, complaints, message type, recipient lists
Spam rate increases	Recipients are marking more messages as unwanted	Opt-in, list source, frequency, marketing flow, unsubscribe
Delivery errors increase	Return to the actual SMTP responses	Classify 4.x.x, 5.7.1, and other rejections from logs
No data to display	There is not enough data to draw a conclusion	Do not treat an empty chart as proof of good reputation
Compliance shows a problem	A specific sender requirement is not being met	Fix the indicated technical issue before experimenting with reputation

Compare Postmaster Tools with SMTP logs

Postmaster Tools does not replace the bounce message. For one incident, compare six sources:

the complete Gmail bounce;
Postfix or Exim logs;
SPF/DKIM/DMARC for the actual mail flow;
PTR and HELO/EHLO for the real sender IP;
Postmaster Tools;
public DNSBLs as a secondary signal.

If Postmaster shows poor IP reputation while the server also has unknown SMTP AUTH activity, there is little value in changing words in the subject line. If Authentication drops only for website notifications while normal SMTP mail passes, investigate the application's delivery route.

An RBL is one sensor, not a diagnosis of the whole system.

If reporting is available for the verified domain in Postmaster Tools, use it only after fixing the infrastructure and authentication. It does not replace troubleshooting and it is not a universal “remove block” button.

In what order should you troubleshoot Gmail 550-5.7.1?

A reliable order is: bounce, server security, authentication, DNS identity, outbound IP route, reputation, and finally the specific message. If you change SPF, PTR, DKIM selector, IP, and the message template at the same time, even a successful test will not tell you what fixed the problem.

Save the complete Gmail bounce. Not just “mail delivery failed,” but the full SMTP response.
Record the actual sender IP. Use the address involved in the rejected delivery.
Identify the rejection stage. Connection, MAIL FROM, RCPT TO, DATA, or another stage.
Check the queue. Rule out an active spam burst or compromised SMTP account.
Check SPF. Confirm that it authorizes the actual IPv4 or IPv6 address.
Check DKIM. Verify that the message contains a signature and that it passes.
Check DMARC. Verify alignment with the visible From domain.
Check PTR and forward DNS. The IP and hostname should form a sensible two-way DNS identity.
Check HELO/EHLO. Compare both myhostname and the effective smtp_helo_name.
Check IPv6 separately. Do not assume the message was sent over IPv4.
Compare other domains and message types. This helps distinguish IP reputation, domain reputation, and a single problematic template.
Compare the result with Postmaster Tools. If the domain has enough data available.

At the end, instead of “everything looks correct but Gmail hates the IP,” you should have a concrete diagnostic card.

Exact Gmail response:
Sender IP:
SMTP stage:
PTR:
Forward DNS:
HELO/EHLO:
SPF:
DKIM:
DMARC:
IPv6:
Queue anomaly:
Other domains affected:
Postmaster Tools:
Problematic mail flow:

For example:

Sender IP: 203.0.113.x
SPF: pass
DKIM: pass
DMARC: pass
PTR: pass
Other domains affected: no
Only one marketing flow affected: yes

This result no longer suggests changing PTR blindly. The next step is to investigate the specific domain, message template, recipient list, and sending behavior.

Another example:

Sender IP: IPv6
PTR: missing
SPF: IPv4 only
DKIM: pass

Here there is no reason to start with message content. The infrastructure fault is already visible.

First 10-minute checklist

copy the complete Gmail bounce;
record the sender IP;
distinguish 5.x.x from a temporary 4.x.x response;
inspect the mail queue;
rule out an SMTP/PHP spam source;
check SPF for the actual sender IP;
check the real DKIM signature;
check DMARC alignment;
check PTR and A/AAAA;
check HELO/EHLO;
check IPv6 separately;
compare other domains using the same IP.

Change one layer at a time and record the result. Otherwise, after five simultaneous changes, even successful delivery will not reveal the original cause.

How should you restore Gmail delivery after fixing the cause?

The technical root cause and Gmail reputation should be treated separately. SPF can be fixed in minutes and a compromised mailbox password can be changed immediately, but IP or domain reputation does not necessarily change at the same moment.

After a security incident, one of the worst things you can do is immediately retry an old queue containing thousands of messages. It may still contain spam, outdated notifications, and mail to recipients who no longer expect it.

When can the infrastructure be considered fixed?

Before restoring normal mail volume, get the server into a clearly verifiable state. Not “it seems fine,” but a set of concrete checks.

The technical root cause can be considered removed when the main checks are satisfied:

unknown SMTP AUTH sessions no longer appear;
the mail queue does not grow abnormally;
unknown PHP scripts, cron jobs, or CMS processes no longer generate messages;
SPF passes for the actual sender IP;
the DKIM signature is present and valid;
DMARC passes with proper alignment;
PTR and forward DNS are consistent for the IP in use;
HELO/EHLO belongs to the actual outbound MTA;
Gmail sees the IPv4 or IPv6 address the administrator actually intends to use.

This does not mean reputation has already recovered. It means the server has stopped generating a new technical problem and you can now observe how delivery changes.

How should you restore normal mail flow?

separately review or remove the suspicious old queue;
do not automatically retry the old spam-like flow;
restore normal transactional and user-generated messages;
avoid an artificial spike in volume;
monitor new Gmail SMTP responses;
monitor Postmaster Tools if enough domain data is available;
for subscription and marketing mail, maintain proper opt-in and unsubscribe handling.

If the server normally sent only a few dozen expected notifications, do not attempt an artificial “rehabilitation” by sending thousands of test messages after the fix. Restore the traffic the server is actually supposed to send.

What signals show that the situation is improving?

Do not judge recovery by one Gmail test mailbox. Look at the combined evidence:

new messages stop receiving the same permanent rejection;
the share of failed deliveries in the logs decreases;
authentication remains stable after the changes;
the queue does not accumulate new suspicious traffic;
available Postmaster Tools indicators improve over time;
no new issue appears when switching between IPv4, IPv6, or different mail flows.

There is no universal promise such as “Gmail will unblock the IP within 24 hours.” A single PTR error, a new IP with no negative history, and a server that spent a long period sending unwanted mail after compromise are very different cases.

Do not keep changing IP addresses every few days either. If the source of bad traffic remains active, the new address can develop the same problem. If the rejection is tied to domain reputation or a particular mail flow, changing the IP does not remove the root cause at all.

Do not confuse one successful delivery with recovery. A single accepted Gmail message only proves that one attempt worked. A healthy state means the expected mail flow consistently passes authentication, the server generates no unknown traffic, and new SMTP responses no longer reproduce the previous rejection pattern.

If legitimate mail continues to be rejected after all technical checks, you can move on to official troubleshooting and reporting channels for a verified domain, where available. Doing this earlier is of limited value: first you need a known sender IP, a clean queue, correct authentication, and a consistent SMTP/DNS identity.

A practical end state is specific: the actual sender IP is known, Postfix or Exim uses the intended outbound route, the queue is clean, the source of unwanted mail has been removed, SPF/DKIM/DMARC pass, PTR and HELO/EHLO have been checked, and further changes are monitored through new Gmail rejections and Postmaster Tools data. If SMTP delivery already works and the problem has shifted to the receiving side, use the separate guide on why emails are not arriving in Gmail.