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.
After some research, your question made me realize that I had the same problem in my mail server, so first of all, thanx.
Second, you should note that, by default, postfix blocks this kind of traffic. In the manual smtpd_reject_unlisted_recipient:
smtpd_reject_unlisted_recipient (default: yes)
Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages.
So, why are you getting 250 OK
for unknown destination mails? Because of these lines:
mydestination = $myhostname, localhost.$mydomain, localhost
virtual_alias_maps = hash:/etc/postfix/virtual
The smtpd_reject_unlisted_recipient
checks destination mails but very specifically:
An address is always considered "known" when it matches a virtual(5) alias or a canonical(5) mapping.
The recipient domain matches $mydestination, $inet_interfaces or $proxy_interfaces, but the recipient is not listed in $local_recipient_maps, and $local_recipient_maps is not null.
The recipient domain matches $virtual_alias_domains but the recipient is not listed in $virtual_alias_maps.
The recipient domain matches $virtual_mailbox_domains but the recipient is not listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null.
The recipient domain matches $relay_domains but the recipient is not listed in $relay_recipient_maps, and $relay_recipient_maps is not null.
As your mydestination
does not include your $mydomain
(only the servername and localhost) and you do not have any *_domains
in place, there are no other checks for "known" destinations.
You only need to add:
virtual_alias_domains = $mydomain
an reload postfix. (If I'm getting your config right and all your mail are in the form "user@domain.com")
If that does not work, you might try this:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
NOTE: it will check via RCPT TO
command if the destination trully exists for both incoming and outgoing messages. Use with caution since it makes an extra connection for each new destination and will take some time to respond to every mail your server processes (It can take a few seconds to test each destination).
Best Answer
If you will forgive me, I'm not sure you quite understand greylisting. As Mimecast's docs say, the identifier for a greylisting decision is a triplet:
When delivery is attempted of an email with a previously unseen triplet, greylisting should temporarily knock it back. When that particular email tries to be redelivered from the same server, it should be accepted, and that specific triplet gets written to a temporary whitelist.
Further emails with the same triplet arriving within the lifetime of the whitelist entry should be delivered. If you have evidence of any of this not happening, it would be of interest.
But further emails from other senders at your domain, or to different recipients, should quite properly be greylisted. Your server doesn't suddenly get carte blanche to send emails simply because it successfully delivered a single piece of mail.
Most recipients do not choose to greylist based on the existence of valid SPF and/or PTR records, nor your IP's presence on blacklists (or the lack thereof), so your accomplishments there—whilst likely to be of help further down the anti-spam chain—are probably not relevant to greylisting.
Greylisting is generally applied to all incoming email, though some implementations do exempt any email that arrives under cover of
SMTP TLS
, presumably reasoning that very few fire-and-forget bots can properly do TLS (yet).