How to ignore DMARC or properly adjust?
Question asked by Steve Guluk - March 11, 2015 at 1:26 PM
Unanswered
Hello, 
I keep getting this error from Google sent emails:
 
 
 
Delivery to the following recipient failed permanently:

 steve @ sgdesign . com

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the server for the recipient domain  sgdesign . com by  mail . sgdesign . net[174.143.222.97].

The error that the other server returned was:
550 Message rejected due to senders DMARC policy
 
 
How do we allow services like Google to send mail to our server in regards to the DMARC policy?

7 Replies

Reply to Thread
0
Bruce Barnes Replied
Chech your DMARC DNS entries. See www.unlocktheinbox.com fto make certain you three DMARC DNS entries are valid and then send a test message check your settings again.
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Steve Guluk Replied
Hi Bruce, I found that under Security /  Antispam / Options / Enable DMARC policy compliance check       was selected and this is what was blocking Google mail as I also read Google does not run DMARC on any of their servers.
1
Bruce Barnes Replied

Google is actively promoting DMARC.  See the articles and links below: - all from Google, and about Google's use, and promotion of, DMARC:

Google also checks ALL INCOMING E-MAIL for DMARC 
records

There are some very specific items which must be setup for DMARC in SmarterMail, or any other MX SERVER:
 
  • DOMAINKEYS (2048 bit - all 1024 bit keys, for everything, were depreciated by Microsoft and US CERT in December, 2014 because of the ability to hack smaller keys easily)
  • DKIM
DKIM requires no DNS record
 
 
once you set those up, you must setup the following items:
  • rDNS - must be setup by the company which provides your STATIC IP ADDRESSES
    • SPF - must be setup in YOUR PRIMARY DNS SERVER
      • DOMAINKEY entries in DNS - there are THREE TOTAL
      • the DOMAIN KEY, a TXT record
        • which contains THREE RECORDS, shown as:
      • Entered in DNS as:
  • DMARC RECORD: must be setup in your PRIMARY DNS SERVER
    • Not all DNS servers support 2048 bit DMARC records, but anything smaller than 2048 bit will be rejected by GOOGLE, so plan on updating your DNS if it doesn't support 2048 bit TXT records - which is how a DMARC record is added - as a TXT record.
    • Microsoft DNS does support 2048 bit TXT records
 Note about DNS SERVERS: you should have at least TWO, with the new standard being THREE.  The PRIMARY will auto-feed everything to the 2nd and 3rd DNS servers.
 
Here's my DMARC RECORD:
 
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@chicagonettech.com!10m; ruf=mailto:dmarc@chicagonettech.com!10m; rf=afrf; pct=100; ri=86400
 
It's entered as a TXT record in DNS.
 
the e-mail address, dmarc@chicagonettech.com accepts the DMARC reports and forwards them directly to DMARCIAN at dmarcian.com, which translates the data and sends me reports on anyone trying to hack or spoof my e-mail.
 
we've had ZERO PROBLEMS with DMARC and have been running it for two years now - on ALL HOSTED DOMAINS.
 
DMARC eliminates JOE JOBBING (see: http://en.wikipedia.org/wiki/Joe_job)
 
DMARC will save your MX server's reputation and keep you out of trouble!

==================================
Google Apps features that protect against spoofing

Spoofing occurs when a spammer forges the From address on a mail message so that the message appears to come from a domain that didn’t actually send it. Both Postini and Google Apps provide several tools to protect against spoofing:

  • Creating an Sender Policy Framework (SPF) record
  • Adding a DomainKeys Identified Mail (DKIM) digital signature
  • Creating a Domain-based Message Authentication, Reporting, and Conformance (DMARC) record
  • Allowing messages from certain IP addresses only within the domain

For message senders, these tools let the sender provide information to recipients to help the recipients identify if someone is spoofing that sender’s email address. For message recipients, these tools provide a way to identify incoming spoofed messages.

See: https://support.google.com/a/answer/6081583?hl=en

==================================

Control unauthenticated mail from your domain

Emails not delivered to Gmail?

If you sent an email to a Gmail user and got an automatic bounce message that says, "Unauthenticated email from [email domain] is not accepted due to domain's DMARC policy,” see the options below for more information:

  • If you sent the email using Gmail, learn how to fix your settings in Gmail.
  • If you sent the email using a different email application, try looking for a setting in your email application that controls the server used to send messages (the “outgoing” server). Change this setting so that you’re using the server that matches the email address you want to send from. If that doesn’t work or you need more help, contact the email provider for your email address.

To help fight spam and abuse, Gmail uses email authentication to verify if a message was actually sent from the address it appears to be sent from. As part of the DMARC initiative, Google allows domain owners to help define how we handle unauthenticated messages that falsely claim to be from your domain.

What you can do

Domain owners can publish a policy telling Gmail and other participating email providers how to handle messages that are sent from your domain but aren’t authenticated. By defining a policy, you can help combat phishing to protect users and your reputation.

On the DMARC website, learn how to publish your policy, or see the instructions for Google Apps domains.

Here are some things to keep in mind:

  • You'll receive a daily report from each participating email provider so you can see how often your emails are authenticated and how often invalid emails are identified.
  • You might want to adjust your policy as you learn from the data in these reports. For example, you might adjust your actionable policies from “monitor” to “quarantine” to “reject” as you become more confident that your own messages will all be authenticated.
  • Your policy can be strict or relaxed. For example, eBay and PayPal publish a policy requiring all of their mail to be authenticated in order to appear in someone's inbox. In accordance with their policy, Google rejects all messages from eBay or PayPal that aren’t authenticated
 
 
==================================

Prevent outgoing spam with DMARC

Add a DMARC record

Create the record

Once SPF and DKIM are in place, you configure DMARC by adding policies to your domain's DNS records in the form of TXT records (just like with SPF or ADSP).

Important: Before creating a DMARC record for your Google Apps domain, you must first set up DKIM authentication. If you fail to set up DKIM first, email from services such as Google Calendar will fail mail authentication and will not be delivered to users.

Follow the instructions to create a TXT record with the appropriate name and value, using the specific instructions for popular domain hosts. The TXT record name should be "_dmarc.your_domain.com." where "your_domain.com" is replaced with your actual domain name. You can also review the limitations with some domain hosts.

https://support.google.com/a/answer/2466563?hl=en

 
==================================

Prevent outgoing spam with DMARC

Understand DMARC

Prevent outgoing spam with DMARC

Understand DMARC

Overview

Spammers can sometimes forge the "From" address on mail messages so the spam appears to come from a user in your domain. To help prevent this sort of abuse, Google is participating in DMARC.org, which gives domain owners more control over what Gmail does with spam emails from their domain.

Google Apps follows the DMARC.org standard and allows you to decide how Gmail treats unauthenticated emails coming from your domain. Domain owners can publish a policy telling Gmail and other participating email providers how to handle unauthenticated messages sent from their domain. By defining a policy, you can help combat phishing to protect users and your reputation.

Prerequisites

Please note, you must send all mail through your own domain for DMARC to be effective. Mail sent on your behalf through third-party providers will appear unauthenticated and therefore may be rejected, depending upon your policy disposition. To authenticate mail sent from third-party providers, either share your DKIM key with them for inclusion on messages or have them relay mail through your network.

If you're a domain owner, you'll first need to configure SPF records and DKIM keys on all outbound mail streams. DMARC relies upon these technologies to ensure signature integrity. A message must fail both SPF and DKIM checks to also fail DMARC. A single check failure using either technology allows the message to pass DMARC. See the corresponding SPF and DKIM sections of the DMARC specification for example messages filtered by these tools.

https://support.google.com/a/answer/2466580?hl=en

 
==================================
 
The best DMARC and SPF creation tools I have found are at www.unlocktheinbox.com.  

Once you have setup everything, send a test message, from a valid account on your SmarterMail server, to mailtest@unlocktheinbox.com
 
The response will show you all aspects of your MX server configuration and tell you what needs to be fixed to make SPF, rDNS, DOMAINKEYS, DKIM and/or DMARC work properly.

Here's a portion of a response, showing everything working properly for one of my customer's SmarterMail servers:

 
Publication: RFC 4408
SPF Records
SmarterMail Check: Passed
ARSoft Check: Passed
SpamAssassin Check: Passed
SPF DNS Location: Click Here: REDACTED.com
SPF Record in TXT (TYPE 16): v=spf1 mx a ip4:999.999.999.99 ip4:999.999.999.998 ~all
IP ADDRESSES REDACTED
(TYPE 16) Syntax: Passed
SPF Record in SPF (TYPE 99): Not Found - Learn about SPF (TYPE 99) Click Here
 
Information: Identifier Alignments
SPF Alignment Test (Used in DMARC ASPF Test)
Mail From/Return Path Domain: REDACTED.com
From Domain: REDACTED.com
SPF Identifier Alignment: Strict
 
Publication: RFC 4406
Sender ID
Sender ID Check: Passed
Sender ID Record: Uses SPF implementation above
 
Publication: RFC 4870
Domain Keys Additional Information (Obsolete)
Tag Value
Key Algorithm: a=rsa-sha1 (must be SHA256 as of 1 April, 2016)
Canonicalization: c=simple
Query Method: q=dns
Domain Name: d=REDACTED.com
Selector: s=secure
Signed Headers: h=received:from:to:subject:date:reply-to:message-id:mime-version :content-type:x-originating-ip
Signature Data: b=Uss8YljZmrNpN04tLTvKWlMsHrZE3M515QzkZ/ld9fWEtlzEF6TBE7omJWqFhSbpw RGbuW8FKqZ14B2ZVEOxGs7MzPl5rEvnvdmIdBCldAF2WYZu6AtVxu0OY2Rg6JPNI7 tES8Idrz8qPaXVGS17Eagv/bq029TDcBMhA9qYOLXMhUClmVTxzCQXF3k8lxkrG4t D3gePrONKNPkNaqQb8FNP7XZCNfqWlXpEAvUXEkLkrnsTn2/xT4Q+/xsIn2E+n20x s8rROmS0fE+PEidonX8f6PSVNAXONfyyZYGSUBHRxjaKrYvlSh9oCAGEhCS/B58S0 EcmZ4Op82ZhlmKvvQ==
 
Domain Keys Check (Obsolete)
Signature Found: Yes
SM Signature Verification: Passed
From Signed: Yes
Restricted Headers Signed: N/A
 
Public Domain Key (Obsolete)
Selector Location: Click Here: secure._domainkey.REDACTED.com
DNS Record Found: Yes
Record Syntax: k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtOK1Kr3N219+0cklMJzYVRzaleNWpqsfo5bOQDQ5sJvOBvO/TdhdgoqF4eCWPDGdrP86fKPvCp1TlgGA+2PI3Yy7FZtnTRWQIoYDCbcw4ZhPbB76PhYq72D7IAIP9eu1/4s11ni95AeP+eKzBCvkmXA3ogGm1kjoD/k404NzRh8r5Gkh7K1TUSjTIL/quwHKNGWUd78Btyv6oGByug+HZD+3RlHqX+E4gelGUQCKBJZS5xmumYRl9hehcjpDNzDeFxWwaSoR495z5QtllcyIKJdJYCB9pjZeLVMr8mecfcaruaPmmjLRYRDZQk7sDQwjsyC5KVTk3GvG1scIEk1pNQIDAQAB
Key Size: 2048
 
Publication: RFC 6376
DKIM Signature Additional Information
Tag Value
Version: v=1
Key Algorithm: a=rsa-sha256
Canonicalization: c=simple/simple
Domain Name: d=REDACTED.com
Selector: s=secure
Signed Headers: h=x-originating-ip:content-type:mime-version:message-id:reply-to :date:subject:to:from
Body Hash: bh=SK/6XswJedgxUWxICi4PZiREQpskF8cDfsmKgaVOIP8=
Signature Data: b=OhHUpPHEB/7GQKoi4BxxQpnPwQ1pyg0GFK3LfR3g1077B6gn6kbntlCi0V7w18nez e9NI77/8RQHrOweRo3bpV8HkYggOz6Fd9gThtKnsClGdVNgzG5angapAIs144dexH 4Vr33xCSseVJf2exR5Tktwu7841c3sJ+gUx2W/x4xeyHF2g1CgUXr27F2q45WXrg9 e5uFwYV9m/iWEZ7XFiuJPbVPiLDjZcWrWGL4HriZ3u0RuAwic/GpL+mT1E1ik7ooo iUgcYI/TJJZmbxIxpMF3UOhj4psA37sWydAhTF4AQnq3Xldi/vu3jj29MUyAATzUZ h23+T7ajknywWlSCg==
 
Publication: RFC 6376
DKIM Check
Signature Found: Yes
SmarterMail DKIM Test: Passed
LimiLabs DKIM Test: Passed
SpamAssassin DKIM Test: Passed
From Signed: Yes
Restricted Headers Signed: No
 
Public DKIM Key
Selector Location: Click Here: secure._domainkey.REDACTED.com
DNS Record Found: Yes
Record Syntax: k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtOK1Kr3N219+0cklMJzYVRzaleNWpqsfo5bOQDQ5sJvOBvO/TdhdgoqF4eCWPDGdrP86fKPvCp1TlgGA+2PI3Yy7FZtnTRWQIoYDCbcw4ZhPbB76PhYq72D7IAIP9eu1/4s11ni95AeP+eKzBCvkmXA3ogGm1kjoD/k404NzRh8r5Gkh7K1TUSjTIL/quwHKNGWUd78Btyv6oGByug+HZD+3RlHqX+E4gelGUQCKBJZS5xmumYRl9hehcjpDNzDeFxWwaSoR495z5QtllcyIKJdJYCB9pjZeLVMr8mecfcaruaPmmjLRYRDZQk7sDQwjsyC5KVTk3GvG1scIEk1pNQIDAQAB
Key Size: 2048 bits
 
Information: Identifier Alignments
DKIM Alignment Test (Used in DMARC ADKIM Test)
DKIM d= Tag: REDACTED.com
From Domain: REDACTED.com
DKIM Identifier Alignment: Strict
 
Draft Publication: DMARC Base-00-02
DMARC Check
Record Syntax: Passed
DKIM Test: Passed
SPF Test: Passed
ADKIM Test: Passed
ASPF Test: Passed
RUA Test: Passed
RUF Test: Passed
DMARC Passed: Yes
DMARC Record Location: Click Here: _dmarc.REDACTED.com
DMARC Record: v=DMARC1; p=none; sp=none; adkim=s; aspf=s; rua=mailto:dmarc@REDACTED.com; ruf=mailto:dmarc@REDACTED.com; rf=afrf; pct=100; ri=86400
 
Publication: RFC 5617
ADSP (Author Domain Signing Policy) Check (HISTORIC)
ADSP Record: dkim=all;
ADSP Record Syntax: Passed
ADSP Record Location: Click Here: _adsp._domainkey.REDACTED.com
 
Publication: RFC 822 (6.3)RFC 1123 (5.2.7)RFC 2821 (4.5.1)
Acceptance of Postmaster Address
postmaster@mydatapage.com Passed
 
Acceptance of Abuse Address
abuse@mydatapage.com Passed
 
Spam Assassian Results
Content analysis details: (You scored -2.7 points, 5.0 or higher is considered to be spam)
 
Pts Rule Name Description
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
    [score: 0.0000]
0.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
    domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 TVD_SPACE_RATIO No Description available.
 
Email Authentication Knowledge Base
If you failed any of the tests above, please visit our Email Authentication Knowledge Base.
 
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Bruce Barnes Replied
PS: This is one time having a RESIZABLE REPLY BOX would have been EXTREMELY HELPFUL!
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Robbie Wright Replied
Steve, if you can't tell from Steve's response, DMARC can be complicated but is becoming a necessity to understand and utilize. SPF, DKIM, and DMARC together make for a very effective method of preventing certain types of phishing and domain spoofing. Your box for DMARC compliance should be checked. If an entity config's DMARC on their domain, they are telling the world what to do with their email if it comes from a server that doesn't belong to the domain. Google is just enforcing their wishes and you should too.
 
Like Steve said, make sure SPF and DKIM are setup correctly, then configure DMARC. 
 
Steve, adsp is generally not used anymore...
0
Bruce Barnes Replied
The most recent DMARC Technical Specification, dated 5 February, 2015, is reflected here: 
 
https://dmarc.org/resources/specification/, and, with relation to ADSP failures states the following . . .
 
 

Related Specifications

The following specifications, listed alphabetically, are related to DMARC in various ways.

Authentication Failure Reporting Format (AFRF) (RFC6591)

  • A new report sub-type extension for the Abuse Report Format (ARF) (see: RFC 5965)
  • Allows for relaying of forensic details regarding an authentication failure
  • Supports reporting of SPF and/or DKIM failures
    • For SPF, reports the client IP address and the SPF record(s) that were retrieved, producing a “fail” result
    • For DKIM, reports the canonicalized header and body that produced a failed signature, allowing forensic analysis by the signer to detect why the failure occurred
    • Also supports ADSP reporting of messages that weren’t signed but should have been
  • This will be used by DMARC sites for reporting per-message failure details.
  • An aggregate reporting format is suggested within an appendix of the DMARC specification.
 
by virtue of the fact that the protocol now "supports ADSP reporting of messages that weren't signed, but should have been," this leads me to believe that this supersedes Robbie's comment that ADSP is "not used any more"
 

"Steve, adsp is generally not used anymore...

 
but in fact should be included in every DMARC record.
 
 
 
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Robbie Wright Replied
Could go either way I suppose. The RFC is historic as of 2 years ago and the definition of historic, in this instance is:

The label Historic is applied to deprecated Standards Track documents or obsolete RFCs that were published before the Standards Track was established.

Just because the AFRF still supports it in the protocol doesn't mean the actual RFC is still valid.

Not sure it matters though. Keep up the good work Bruce.

Reply to Thread