I have trouble sending email to GMail addresses using IPv6 from my domain camgirltools.net

If IPv4 is used, everything works as intended, the mail is delivered. When using IPv6 to send mail to GMail (other parties work) I get a bounce mail back:

host ASPMX.L.GOOGLE.COM[2607:f8b0:4003:c08::1a] said:

550-5.7.1 [2a02:748:a800:ca7:ea75:b12d:f:20 12] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for more information.

j124si9092437oia.0 - gsmtp (in reply to end of DATA command)

(removed unnecessary repetitions of the error code mid-message for better readability)

I do NOT send bulk messages, I get the same error for every individual (and unique) message I send. The same message (headers, data) works over IPv4.

Google states in the documents linked at the help page given in the error message, that:

To ensure that Gmail can identify you:

  • Use a consistent IP address to send bulk mail.
  • Keep valid reverse DNS records for the IP address(es) from which you send mail, pointing to your domain. Use the same address in the 'From:' header on every bulk mail you send.

We also recommend the following:

  • Sign messages with DKIM. We do not authenticate messages signed with keys using fewer than 1024 bits.
  • Publish an SPF record.
  • Publish a DMARC policy.

Additional guidelines for IPv6

  • The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
  • The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.

From what I can tell, my server and DNS configuration fulfills all these requirements:

  • Consistent IPs are used (Postfix settings below)
  • Reverse DNS is there, equally for IPv4 and IPv6 (DNS Records below)
  • I use DKIM and it's confirmed working for IPv4, there should be no differences to IPv6. Also, DMARC specifies "none".
  • SPF is used and valid, confirmed working for IPv4, there should be no difference to IPv6 besides the IP used (and IPv6 is present in the SPF record). Also, DMARC specifies "none".
  • DMARC is present and confirmed working

  • Sending IP has PTR, matches the IP obtained via forward DNS (DNS entries see below, Postfix config for IP used see below, also the bounce mail states clearly that the correct IP has been used)

  • Sending domain passes SPF and DKIM, confirmed working for IPv4 and for other targets but GMail.

Neither my domain nor any of my IP addresses can be found on any blacklist (feel free to check: domain, IPv4, IPv6), and they haven't been blacklisted by Google either (error message for that states "IP has been blacklisted" instead of "message has been blocked".

My DNS records look like this (roughly sorted by relevance for this question):

$ dig -tany camgirltools.net
camgirltools.net.                 3599 IN    A
camgirltools.net.                 3599 IN AAAA 2a02:748:a800:ca7:ea75:b12d:f:20
camgirltools.net.                 3599 IN   MX 0 camgirltools.net.
camgirltools.net.                 3599 IN  TXT "v=spf1 ip4: ip6:2a02:748:a800:ca7:ea75:b12d:f:20 mx include:_spf.google.com -all"
camgirltools.net.                21599 IN   NS ns1.camgirltools.net.
camgirltools.net.                21599 IN   NS ns2.camgirltools.net.
camgirltools.net.                21599 IN   NS ns3.camgirltools.net.
camgirltools.net.                21599 IN   NS ns4.camgirltools.net.
camgirltools.net.                21599 IN   NS ns5.camgirltools.net.
camgirltools.net.                21599 IN  SOA ns1.camgirltools.net. hostmaster.camgirltools.net. 2014121507 10800 3600 604800 3600

$ dig -tany mail._domainkey.camgirltools.net
mail._domainkey.camgirltools.net. 3599 IN  TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyohctAU5fDdWFEtbVNny85RCMVXZLto01bWc3adSQMVJ9w7HQXaTuq/j10Fip70VxqeyL2bXsz8yg9Xb3NQ6yGqPINBqSKG2pduDNahsjXj/y/nstXiXXkXMEH8JLlBEwNM//GWgjHkL/2B75hTx+7j5sh010qhv6vyHkTEFDgwIDAQAB"

$ dig -tany _dmarc.camgirltools.net
_dmarc.camgirltools.net.          3599 IN  TXT "v=DMARC1\; p=none\; sp=none\; aspf=r\; adkim=r\; rua=mailto:[email protected]\;"

$ dig -x    14399 IN  PTR camgirltools.net.

$ dig -x 2a02:748:a800:ca7:ea75:b12d:f:20
                                 14399 IN  PTR camgirltools.net.

DKIM and SPF have been tested and work for IPv4, glue records for DNS are all fine.

Relevant parts from Postfix config (feel free to ask for more parameters if needed):

mydomain           = camgirltools.net
myhostname         = $mydomain
inet_interfaces    = all
inet_protocols     = all
smtp_bind_address6 = 2a02:748:a800:ca7:ea75:b12d:f:20

Skipped DKIM config as it's working for IPv4, but I can provide it if needed.

So - what do I miss here?

  • 3
    You missed nothing. Gmail is broken. Dec 29, 2014 at 17:58
  • So, @MichaelHampton, you're saying the only solution is switch to v4 only, until GMail dies? Dec 29, 2014 at 17:59
  • 2
    I stopped using Gmail in protest. Not that I expect it to do much good. If you have any luck with locating the person at Google responsible for this massive screwup, please let us all know. Dec 29, 2014 at 18:31
  • 1
    I never even started using Gmail. Unfortunately people that my clients might want to reach do. Dec 29, 2014 at 18:37
  • 1
    @Nicholas that's an entirely different topic. I'M trying to send email TO Gmail FROM MY server. You're sending FROM Gmail. Jan 3, 2015 at 20:06

4 Answers 4


I have no problems sending email to GMail over IPv6. However, I have a dedicated sub-domain for my mail server. (In my experience and research, I have found second level domains are most likely spammers.)

IPv6 tends to be much easier to configure correctly for email serves (rDNS) etc. You might be flagged as the address you are using looks like it may be based on the MAC address. Try configuring the address so that you can use "::" in it.

The MX in your SPF record is redundant as the IP specification already specify the addresses. Also, including Google's SPF record if you aren't using them as an MX may be a flag. I believe their ~all policy will trump your -all policy.

MX priorities are usually non-zero, you may want to try 10 instead.

  • Including google is on purpose, as I want to allow clients to use their GMail webmail to send accounts from that domain. I'm fully aware that mx AND naming the IPs manually is redundant, and I plan to get rid of the MX part - but I was usign different IP addresses to test, and was too lazy to change the SPF every time. Jan 3, 2015 at 20:05
  • Mind to elaborate the "looks like it may be beased on the MAC address" part? I didn't quite get what you are trying to say there. Jan 3, 2015 at 20:05
  • @JohannesH. IPv6 has a mechanism to generate the last 64 bits of the address using the MAC address. This results in addresses with lots of bits set. When addresses are manually assigned they usually two or three address sections are 0 and can be replaced by ::. You could use something like 2a02:748:a800:ca7::25. Users using privacy extensions would also have address sections with no zeros, but the addresses change periodically.
    – BillThor
    Jan 4, 2015 at 1:34
  • I can assign any IP address within the 2a02:748:a800:ca7:ea75:b12d:f:0/112 subnet - and that's it. I have to work with that. So I'm afraid I can't do much here. But TBH, if THAT is the issue GMail refuses to deliver email sent from my server, then Google definately went fully paranoid on this. Jan 17, 2015 at 15:44

I had a similar issue (e-mails were accepted by Gmail if sent over IPv4 but bounced when sent over IPv6) and I figured out the issue was that the hostname used in the SMTP HELO command was not the fully qualified name of the server and had no AAAA record (actually, it was a simple without any tld). So, all I did was editing the /etc/hostname file to match the fqdn of the server and in once Google started accepting my e-mails over IPv6.

I'm not sure why it doesn't have the same behaviour on IPv4 though....

  • 1
    In my case, this is not the issue, my HELO uses a fqdn and the AAAA records for it are properly set up. Dec 5, 2016 at 21:13

I have experienced this problem on multiple systems - rDNS enabled, SPF record in place which allowed sending from the IPv6 address, no problems with any service but Gmail (and G-Suite) users.

I usually am against disabling IPv6, but it was necessary here. So for all mail going to Google's email hosts, I disabled IPv6: Open /etc/postfix/master.cf and add this at the end:

smtp-ipv4     unix  -       -       -       -       -       smtp -o inet_protocols=ipv4

Now open /etc/postfix/main.cf And add hash:/etc/postfix/transport to transport_maps =

Now open /etc/postfix/transport and add:

gmail.com smtp-ipv4:
google.com smtp-ipv4:
*.google.com smtp-ipv4:
googlemail.com smtp-ipv4:
*.googlemail.com smtp-ipv4:

To finalize, run postmap and restart postfix:

postmap /etc/postfix/transport
systemctl restart postfix
  • Thanks for posting this workaround. While I have by now found a work around (I posted it as an answer myself just now), this might help people who run into the same problem. Apr 13, 2021 at 22:08

I completely forgot about this question. While the issue still persists, I have somehow "solved" it (well, I found a way to work around the issue) by using a smtp reply filter.

in main.cf:

smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter_gmailError


# Convert permanent error in a temporary one if the reason is GMail complaining
# just because we used IPv6- Postfix will retry to deliver using another MX,
# now using IPv4
/^5(\d\d )5(.*information. \S+ - gsmtp.*)/ 4${1}4$2

The comment in the filter file pretty much explains all about how this is working: if postfix encounters a reply matching the regular expression in the filter (left hand side), it will instead treat it as the error code at the right hand side. Essentially, it converts any 5xx error code to a 4xx error code if the message contains "information" and "gsmtp". Now, 4xx errors are, in contrast to 5xx, only temporary - so postfix will queue the email again and attempt to deliver it another time - this time using another MX if more than one is specified for the receiving domain. As google publishes A and AAAA records for all their servers, if the IPv6 entry failed, the next one will be the IPv4 one - which will take the email.

In contrast to @Thom workaround, this approach allows to keep IPv6 enabled even for gmail (in case the error disappears for a domain) but still deliver email successfully over IPv4 if needed.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .