How to avoid messages rejection because of DMARC when sent through Gmail alias

dkimdomain-name-systememailgmailspf

Many people add
' another email address as alias ' for their Gmail accounts – talking here about public Gmail not Google Apps – and they may use Gmail server not their domain servers as SMTP with the ' Treat as an 'alias' setting '. While DMARC not causing any problems with "none", It causes messages be rejected by servers like Hotmail, Yahoo and others when sent by Gmail using "another address" because of DMARC p="reject" or p="quarantine".

Here's an example for rejected message:

Rejected By Yahoo,

Delivery to the following recipient failed permanently:

anyuser@ymail.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for 
the recipient domain ymail.com by mta6.am0.yahoodns.net. [98.136.216.26].

The error that the other server returned was:
554 5.7.9 Message not accepted for policy reasons.  
See http://postmaster.yahoo.com/errors/postmaster-28.html

Rejected By Hotmail

Delivery to the following recipient failed permanently:

anyuser@msn.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for 
the recipient domain msn.com by mx3.hotmail.com. [65.55.37.72].

The error that the other server returned was:
550 5.7.0 (COL0-MC1-F8) Unfortunately, messages from (209.85.216.195) on 
behalf of (any-domain-com) could not be delivered due to domain owner 
policy restrictions.

Although the efficiency of DMARC record we still can't do any workaround except asking receivers to whitelist these servers as “known forwarders” which is not a solution!

Anyone knows another way to keep using such a feature at Gmail with DMARC reject and quarantine policies?

Update:

The SPF for the domain is set to don't allow all others:

Domain SPF
v=spf1 mx include:somehost.net -all (same when used ~all or even inclode:_spf.google.com)

somehost.net SPF
ip4:1.2.3.4 ip4:5.6.7.8 -all

The DKIM & SPF for both domain and host used to receive pass result and messages used to reach Yahoo and Hotmail until the "reject" policy set for DMARC of the domain.

When I change "treat as an alias" in Gmail to "Use Domain SMTP servers" it sends normally for sure.

Same thing happening with Yahoo custom From account … other providers bounce back messages.

Update 2

I opened a discussion at the dmarc-discuss and the replied "noway (it's a feature of dmarc)" ….
look here medusa.blackops.org/pipermail/dmarc-discuss/2013-March/001684.html and here medusa.blackops.org/pipermail/dmarc-discuss/2013-March/001692.html … very bad 🙁 .. I will not use then

Best Answer

It sounds like you want to work around the policy being stated in the dmarc record. It is most effective when the policy all mail using the domain are sent by mail servers under control of the domain. This should apply to Banks, Airlines, Couriers, Governments and other senders where it is important to prevent address spoofing.

If you do need to send from GMail using the other domain, then that domain needs to add Google as a valid source or use as weak policy like 'none'. If you send to mailing lists from a protected domain, you are likely to experience similar problems.

Edit: The Reply-To header is a useful to handle cases were mail is sent on behalf someone else. The From header should contain the real sender. The Reply-To address should be an address for the requesting party. DMarc policies would apply to the real sender and follow their spoofing policy. I checked and GMail does not allow use of reply to headers. (Too many automated senders don't apply this approach.)

For adding GMail to your SPF record follow the redirect and include trail. I expect you can get away with including only _netblocks.google.com although you would need _netblocks2.google.com for IPv6 support. I think your policy overrides the included ?all policy.

Using a separate domain or sub-domain for mailing lists, and third party senders is also an option. Set a looser policy for this domain. Providing separate sub-domains to each organization sending mail on your behalf is a good policy option. This will allow you to quickly isolate problems related to a particular organization.

I implemented SPF in response to a storm of SPAM spoofing a domain I controlled. Within a day the flow diminished significantly, and volume was minimal within a week. Finally, the remaining traffic was spam sent to the address which had been harvested.

While some consider DMarc a spam reduction tool, it is really an anti-spoofing tool. As such it can break some edge cases such as mailing lists, and senders using third-party hosts to send mail. In my case, I provide secured access to WebMail, IMap and Mail Submission from out-side the network.

Spoofing reduction may reduced the amount of Spam, but only because senders (spambots) won't be able to pretend to be who they are. Currently, SPF HELO checks are keeping a spambot that claims to be google.com at bay.

Related Topic