Opened 6 years ago

Closed 8 months ago

#9016 closed Bug/Something is broken (fixed)

drupal auto-email notifications getting bounced by yahoo for 'policy' violation

Reported by: HistoriCUSS Owned by: Jamie McClelland
Priority: Medium Component: Tech
Keywords: bounces mail Cc:
Sensitive: no


Beginning 5 April 2014, it seems yahoo began bouncing drupal notification emails from some accounts.

From - Sat Apr 05 21:28:07 2014
X-Account-Key: account3
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Apparently-To: a*** via; Sun, 06 Apr 2014 01:25:40 +0000
Received-SPF: none (domain of does not designate permitted sender hosts)
X-YMailISG: cR_ *** c-
X-Originating-IP: []
Authentication-Results:; domainkeys=neutral (no sig);; dkim=neutral (no sig)
Received: from  (EHLO (
  by with SMTPS; Sun, 06 Apr 2014 01:25:39 +0000
Received: by (Postfix)
	id 85BFA1598A; Sat,  5 Apr 2014 21:25:34 -0400 (EDT)
Date: Sat,  5 Apr 2014 21:25:34 -0400 (EDT)
From: (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: a***
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
Content-Transfer-Encoding: 8bit
Message-Id: <>

This is a MIME-encapsulated message.

Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

This is the mail system at host

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<a***>: host[] said: '''554
    5.7.9 Message not accepted for policy reasons.'''  See
    [] (in reply to end of
    DATA command)

Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns;
X-Postfix-Queue-ID: 93154159A7
X-Postfix-Sender: rfc822; a***
Arrival-Date: Sat,  5 Apr 2014 21:25:32 -0400 (EDT)

Final-Recipient: rfc822; a***
Original-Recipient: rfc822;a***
Action: failed
Status: 5.7.9
Remote-MTA: dns;
Diagnostic-Code: smtp; 554 5.7.9 Message not accepted for policy reasons.  See

Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Return-Path: <a***>
Received: from (localhost [])
	by (Postfix) with ESMTP id 93154159A7
	for <a***>; Sun,  6 Apr 2014 01:25:32 +0000 (UTC)
Received: by (Postfix, from userid 22537)
	id 66C2315977; Sat,  5 Apr 2014 21:25:32 -0400 (EDT)
To: a***
Subject: Account details for dtibbetts at (pending admin approval)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Sender: a***
From: a***
Message-Id: <>
Date: Sat,  5 Apr 2014 21:25:32 -0400 (EDT)
X-Virus-Scanned: ClamAV using ClamSMTP

dtibbetts has applied for an account.


The link provided in the bounce by yahoo includes this:


The latest authentication test that Yahoo has incorporated, DMARC, performs the following checks:

"From" address should map to the same signing domain Mail from a domain should match the domain in the "From" header

Here's an example of a DMARC record:

v=DMARC1; p=quarantine; sp=reject;…

In this example, Yahoo will quarantine emails that fail DKIM and SPF for, and similar emails for sub-domains from will be rejected. The aggregate report will be mailed to

Visit DMARC's website, using the link in this article, to learn how to ensure your messages can be verified.

I am not sure I grasp it all, but it seems to say to me that claiming the email was sent "FROM: A*2@…" when it is originating from the mail server is no longer an acceptable practice at yahoo.

This seems to be a new policy since I was getting these notices over the past few months since creating my hosting orders and I haven't made any recent changes to my account information that would cause this that I can see.

Change History (8)

comment:1 Changed 6 years ago by Dana

Keywords: added; chelsea removed
Owner: set to Ross
Status: newassigned

I'm looping Ross in to help with this.

comment:2 Changed 6 years ago by Ross

Owner: changed from Ross to Jamie McClelland

I think I'm going to need jamie's insights into this problem.

comment:3 Changed 6 years ago by Jamie McClelland

Resolution: fixed
Status: assignedfeedback

See #9029 for more information on the change in Yahoo policy.

The root cause of the problem is not that it's being sent to a Yahoo address, but that it is from a Yahoo address.

If you change the Drupal owner/email address to a non-yahoo address, this problem should go away.

comment:4 Changed 6 years ago by HistoriCUSS

Resolution: fixed
Status: feedbackassigned

In my case, I had the drupal admin email listed as a yahoo.account.

When I went into drupal to address this, it has this cautionary instruction:

"The From address in automated e-mails sent during registration and new password requests, and other notifications. (Use an address ending in your site's domain to help prevent this e-mail being flagged as spam.)

My reading is not that it is FROM a yahoo address per se, but from ANY email domain other than Isn't that what yahoo is now enfocing? a domain match for the FROM field to the email sending server?

I changed the FROM to a gmail address to test. The notices will still be sent to my yahoo account, but my understanding is they will test for a match. Since the FROM will say gmail but they are seeing it come from mayfirst, they will bounce that too.

The real fix is that the FROM field for drupal will have to be a email to match "Received: from"

If I understand, it appears even if I used an email, since it would still be identified as coming from * it too would be bounced by yahoo's new policy.

Or would there be a configuration workaround for that too?

comment:5 Changed 6 years ago by Jamie McClelland

Yes - I think you are on the right track.

The key is to set a from address that won't cause problems if a message originates from one of our servers. May First/People Link doesn't do this - and many other providers allow you to send from any server without penalty.

However, Yahoo (now notoriously) has very strict prohibitions against it and some other providers may have less strict prohibitions.

comment:6 Changed 9 months ago by updater

Sensitive: set

Changed to sensitive as part of leadership decision to make all tickets sensitive.

comment:7 Changed 8 months ago by HistoriCUSS

Sensitive: unset

comment:8 Changed 8 months ago by JaimeV

Resolution: fixed
Status: assignedclosed

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.