SPF, DKIM and DMARC all set but dmarc-reports keep saying the opposite

Question

I'm losing my mind (again) on something about e-mails.

I have a Kimsufi/OVH (Debian Wheezy 7.10) server. I have postfix and dovecot all set.

My main domain/hostname is mywebsite.fr, and i'm using mywebsite.fr set on mywebsite.fr.

I set spf, dkim and dmarc entries in dns zones for both of domains. From contact[at]mywebsite[dot]fr and no-reply[at]mywebsite[dot]fr, all the tests I ran are good :

1) auth-resultats@verifier.port25.com

The Port25 Solutions, Inc. team

==========================================================
 Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  mywebsite.fr
Source IP:      91.121.166.194
mail-from:      contact@mywebsite.fr

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mailfrom=contact@mywebsite.fr
DNS record(s):
    mywebsite.fr. SPF (no records)
    mywebsite.fr. 6055 IN TXT "v=spf1 a mx include:mx.ovh.com ~all"
    mywebsite.fr. 6054 IN A 91.121.166.194

----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result:         neutral (message not signed)
ID(s) verified: header.From=contact@mywebsite.fr
DNS record(s):

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: contact@mywebsite.fr)
ID(s) verified: header.d=mywebsite.fr

2) dmarcian.com

https://dmarcian.com/dmarc-inspector/mywebsite.fr
All seems good

3) dkimvalidator.com

DKIM Information:

DKIM Signature

Message contains this DKIM Signature:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mywebsite.fr;
    s=mail; t=1491673268;
    bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
    h=Date:From:To:Subject:From;
    b=CScyX9ZvWCDL6FGLroXZi/8dFiWmgPbKwcTuSZqPuCHBOR4tv4QdGzxgZ3acWf6AP
     AwAt3Y2h+9IHeayu8mT2rl2Bz3E3XbMC6waEHoc645sAOq1nV9l8hAuw73hm6YsvXU
     QEAgcDIaD8b5fAXoX99rGkSfD6Rx5ygeuJOs0MzZcxnOzaJM+6mvOzusep4PRv0XvG
     eEJYYwL2sNd0qEJSLJ666fhvE781qtwnWaUewlceSgek5bnJ1DVEOsLkcl3uwTabau
     PsLZm9SPuqsc+aDRTTNNRKuI2noO1/w3M6XWfZxpYPIeoxwNnflWxP0s9O6+UbhsCJ
     PJbZeYVATVFKYKjFJlbwAqPMMmJAiqSWzsXvT06/P/Qw70nT5Q9qK1FI8Uu9NRFhWe
     g+35wx03zNG5OMgKzKsv9qH06qccBsbfhHXKm63YkxLDhO+2AtdicdWqrMlZQap7V0
     CC4VyTCNLZdOASWdLJdh8JDsY2TXNU/Pcpxw0uSf0BigY/0q3qj5O7GRzzSLG1rKz0
     +HpvDql/PpsscXt16URaOtO7/rZ6H3EsS1ZkutO5udiwJvoZulraMbI8sQQghR3Yyw
     OZqDardodYdVo1tHzTPQ4MJTEKI+2IO4ulCj7/kJ109xpTYo8+8x3I7Z5Bhmnyui7j
     TIxRT8MCD1sRUOoP7mD/7Pb0=


Signature Information:
v= Version:         1
a= Algorithm:       rsa-sha256
c= Method:          relaxed/relaxed
d= Domain:          mywebsite.fr
s= Selector:        mail
q= Protocol:        
bh=                 g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=
h= Signed Headers:  Date:From:To:Subject:From
b= Data:            CScyX9ZvWCDL6FGLroXZi/8dFiWmgPbKwcTuSZqPuCHBOR4tv4QdGzxgZ3acWf6AP
     AwAt3Y2h+9IHeayu8mT2rl2Bz3E3XbMC6waEHoc645sAOq1nV9l8hAuw73hm6YsvXU
     QEAgcDIaD8b5fAXoX99rGkSfD6Rx5ygeuJOs0MzZcxnOzaJM+6mvOzusep4PRv0XvG
     eEJYYwL2sNd0qEJSLJ666fhvE781qtwnWaUewlceSgek5bnJ1DVEOsLkcl3uwTabau
     PsLZm9SPuqsc+aDRTTNNRKuI2noO1/w3M6XWfZxpYPIeoxwNnflWxP0s9O6+UbhsCJ
     PJbZeYVATVFKYKjFJlbwAqPMMmJAiqSWzsXvT06/P/Qw70nT5Q9qK1FI8Uu9NRFhWe
     g+35wx03zNG5OMgKzKsv9qH06qccBsbfhHXKm63YkxLDhO+2AtdicdWqrMlZQap7V0
     CC4VyTCNLZdOASWdLJdh8JDsY2TXNU/Pcpxw0uSf0BigY/0q3qj5O7GRzzSLG1rKz0
     +HpvDql/PpsscXt16URaOtO7/rZ6H3EsS1ZkutO5udiwJvoZulraMbI8sQQghR3Yyw
     OZqDardodYdVo1tHzTPQ4MJTEKI+2IO4ulCj7/kJ109xpTYo8+8x3I7Z5Bhmnyui7j
     TIxRT8MCD1sRUOoP7mD/7Pb0=
Public Key DNS Lookup

Building DNS Query for mail._domainkey.mywebsite.fr
Retrieved this publickey from DNS: v=DKIM1; k=rsa;p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAomnPCDLufwn5YnIxZ+4veAqdQiTNyk3OsqxTXddGXstKjYefjeJZ/Wgd4vFRheS9DSRjtqLvc66KyM3Ubk37G3S2tXU6dpIPh/poiQuDhdZMWlp829YyR47sYtSSJqFrzd+dKDGfPwrlJb6iIeYksfXOXSHej6s9z1mDobl+fDhORKaB5JySZyPhh/FqCIVMHJffr8tod0Q55MAfRpl38WIJjRjjTXHS2OTNUSQq53kIqSZkx3iFdlxxZh5Tj1DU1bzIGfB4tQaJAGqGhSz4pyzkdc+uVuvXr6NbIrEQ/YnueDHWrbbPoMq77QcToMGqfypgB2CcEU2rlcDYq9aPqYAalv22zY6S0M5FUjlpiHDIR3Hb/ID2ZC2Q/XtCKgaOxr2C4T7Ad0CdcjjQMLnFkOY337U7/P0FgaSQaykiUvSkXDvURgunBv0GLqXfjfwK2Ge8fl+dhYN5bZ/59/GFPcyB/sLHB/cMFWEUyp63RXHBRm+q+c6PMdGIgmoTHYH/0FbYI+/9NHhYOLWhBrgds3x54vStQk0jqYKAipd2494v2dr3p5XlhXU4NEOSEH4FnBfiqoHiYDgjPEIm0ddqH2kBEiuymIoGtWPuBCmY993/1wevOMVjrQlysw2Gf1DZnlbnaytgcSAR0fHgIlLPPoRqGXodvgtW6Zj8ocy71qsCAwEAAQ==
Validating Signature

result = pass
Details: 

SPF Information:

Using this information that I obtained from the headers

Helo Address = mywebsite.fr
From Address = contact@mywebsite.fr
From IP      = 91.121.166.194
SPF Record Lookup

Looking up TXT SPF record for mywebsite.fr
Found the following namesevers for mywebsite.fr: ns.kimsufi.com nsXXXXXX.ip-91-XXX-166.eu
Retrieved this SPF Record: zone updated 20170408 (TTL = 46739)
using authoritative server (ns.kimsufi.com) directly for SPF Check
Result: pass (Mechanism 'a' matched)

Result code: pass
Local Explanation: mywebsite.fr: 91.121.166.194 is authorized to use 'contact@mywebsite.fr' in 'mfrom' identity (mechanism 'a' matched)
spf_header = Received-SPF: pass (mywebsite.fr: 91.121.166.194 is authorized to use 'contact@mywebsite.fr' in 'mfrom' identity (mechanism 'a' matched)) receiver=ip-172-31-3-128.us-west-1.compute.internal; identity=mailfrom; envelope-from="contact@mywebsite.fr"; helo=mywebsite.fr; client-ip=91.121.166.194

Etc, etc, etc.

All seems good and all the mail-testers i'm sending an e-mails are saying "10/10, you're good to go buddy".

The problem is, I receive dmarc-reports and they are not good. For example, last in date from yahoo :

<?xml version="1.0"?>   
<feedback>  
  <report_metadata> 
    <org_name>Yahoo! Inc.</org_name>    
    <email>postmaster@dmarc.yahoo.com</email>   
    <report_id>1491615950.716847</report_id>    
    <date_range>    
      <begin>1491523200</begin> 
      <end>1491609599 </end>    
    </date_range>   
  </report_metadata>    
  <policy_published>    
    <domain>mywebsite.fr</domain>   
    <adkim>r</adkim>    
    <aspf>r</aspf>  
    <p>none</p> 
    <pct>100</pct>  
  </policy_published>   
  <record>  
    <row>   
      <source_ip>91.121.166.194</source_ip> 
      <count>1</count>  
      <policy_evaluated>    
        <disposition>none</disposition> 
        <dkim>fail</dkim>   
        <spf>fail</spf> 
      </policy_evaluated>   
    </row>  
    <identifiers>   
      <header_from>mywebsite.fr</header_from>   
    </identifiers>  
    <auth_results>  
      <dkim>    
        <domain>mywebsite.fr</domain>   
        <result>permerror</result>  
      </dkim>   
      <spf> 
        <domain>mywebsite.fr</domain>   
        <result>pass</result>   
      </spf>    
    </auth_results> 
  </record> 
</feedback>

And last in date from google.com :

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>14868783784049997701</report_id>
    <date_range>
      <begin>1491523200</begin>
      <end>1491609599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>mywebsite.fr</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>2001:41d0:1:e7c2::1</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mywebsite.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>mywebsite.fr</domain>
        <result>fail</result>
        <selector>mail</selector>
      </dkim>
      <spf>
        <domain>mywebsite.fr</domain>
        <result>softfail</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>2001:41d0:1:e7c2::1</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mywebsite.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>mywebsite.fr</domain>
        <result>pass</result>
        <selector>mail</selector>
      </dkim>
      <spf>
        <domain>mywebsite.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

I'm lost, I don't know what to do more than is already set. Don't hesitate ask me more informations, if it can help. Thx...

Did you try `mailtest@unlocktheinbox.com`? It's the most comprehensive tester. — Henry, Apr 08 '17 at 19:41

Henry · Answer 1 · 2017-04-08T20:00:33.163

2

Anyway, looking over your results from those other testers, it looks like you're using a 4096 DKIM, which produces key sizes over 512 bytes. Drop your DKIM size back down to 2048 and I think your issues will go away with the DKIM Failures. I seen numerous instances where large key sizes cause DKIM Failures.

Also the results from google show an ipv6 address as the source IP, I have a feeling Google might be bugged, that is might not be doing the SPF Lookup correctly concerning a and aaaa records, you should add ip6:2001:41d0:1:e7c2::1 to your SPF and see if that resolves the SPF Failures at Google.

In theory, When an ESP receives and ipv6 IP they should look up the aaaa record for SPF if a is specified as a mechanism and a if IPv4 is specified"

edited Apr 08 '17 at 20:00

answered Apr 08 '17 at 19:52

Henry

2,953
2
21
34

Thx ! What you're saying about key size could be the trick, unlocktheinbox is actually saying "753 bytes - UDP can only read up to 512 bytes, some email providers that don't use TCP will not be able to validate your DKIM". The weird thing is it works some times, and so other it does not. I'll try those changes, thx again, I'll keep you in touch. – Vae Apr 08 '17 at 20:12
1

The results look good, you do have to close that poodle vulnerability on that port. You also should create a "postmaster@" account. Also keep in mind, some mail servers have multiple MTA that might be configured different, which can explain the intermittent behavor. The SSL Certificate mis-match can also cause other issue, you can generate free certs at: https://letsencrypt.org/ – Henry Apr 08 '17 at 20:32
Yeah, the Poodle thing is (i hope) now correctly close. The postmaster account is also created. I already have some free certs for my domains. Tbh, I have no idea about how to apply them to the mail thing. – Vae Apr 08 '17 at 21:04
Hum, i'm wondering if I have an other problem. When I send a mail to unlocktheinbox from roundcube, the report is pretty clear and only speaks about `calendridel.fr`(except when it talks about the hostname (`vaeserveur.fr`) ofc). But when I send a mail from my website with php mail(), report is kinda messy with records about `vaeserveur.fr`then about `calendridel.fr` (and it does that for rDNS, email port checks, etc). Maybe it can cause some troubles... Any idea where it could come from ? – Vae Apr 09 '17 at 04:53
It's hard to offer any advice without being able to seeing any relevant data, it looks like the old report from [unlocktheinbox.com](https://www.unlocktheinbox.com/mail-tester/) was removed. Anyway with rDNS focus on the entry that says LSIP - that's the one that matters. The rest is more informational. – Henry Apr 09 '17 at 14:42
Actually I tried DKIMValidator and it returned "result = fail / Details: body has been altered". I had to edit the e-mail content and everything is now good ! I wait for one or two nights and I'll post the whole thing i've done to resolve the thing. Thx for your help @Henry. – Vae Apr 09 '17 at 19:37

score 1 · Answer 2 · edited Oct 07 '21 at 11:07

1

The SPF problem you're seeing is an alignment problem. SPF only counts for DMARC when the Return-Path domain and the Header From domain are on the same organizational domain. In somewhat oversimplified terms, they need to be the same or have a common parent domain that isn't a TLD.

From the reports, you can see that your Return-Path domain (used for SPF) is vaeserveur.fr while the header from domain is calendridel.fr. In this case, it doesn't matter that SPF yields a pass - that pass value won't be used for DMARC. See the discussion here - https://www.rfc-editor.org/rfc/rfc7489#section-3.1

As for DKIM, the other answer is on point. Verifiers don't generally support 4096 bit keys, and they don't actually have to according to the RFC - https://www.rfc-editor.org/rfc/rfc6376#section-3.3.3

edited Oct 07 '21 at 11:07

Community

1
1

answered Apr 08 '17 at 21:57

Peter Goldstein

4,479
2
19
17

Thx, I'll take a loot to the discussions you linked. The thing is, calendridel.fr is on vaeserveur.fr, they are linked and spf returns "pass" a lot of times.... But some other times, it does not. Anyway, I hope the 2048bit keys will be enough to fix it. Once again, thx. – Vae Apr 09 '17 at 04:19
This statement - 'calendridel.fr is on vaeserveur.fr' - is not correct. The fact that the two domains are using the same host or IP address is irrelevant. They are not the same. DMARC is about domains. They aren't the same domain. Read the above note on alignment. – Peter Goldstein Apr 09 '17 at 21:56

SPF, DKIM and DMARC all set but dmarc-reports keep saying the opposite

2 Answers2