DKIM, DomainKeys and SPF test tools · EmailArchitect Support

ivan
100% (Exalted)
Administration Topic Starter

14 years ago

DKIM Test
http://www.appmaildev.com/en/dkim/

DomainKeys Test
http://www.appmaildev.com/en/domainkeys/

SPF Test
http://www.appmaildev.com/en/spf/

If you have any comments or questions about this tool, please add your comments here.

Edited by user 14 years ago | Reason: Not specified

dachande
50.25% (Neutral)
Newbie

11 years ago

#2

Hi,

I tried to use your DKIM Signature Test Tool, but unfortunatly your mailserver (mail.appmaildev.com) tries to identify with an untrusted certificate, so your server got greylistet.

Here is a short excerpt from my postfix logs:


Jan 24 13:12:40 v3-1090 postfix/smtp(20388): certificate verification failed for mail.appmaildev.com(69.89.227.121):25: untrusted issuer /CN=AdminSystem Root
Jan 24 13:12:41 v3-1090 postfix/smtp(20388): A0F2C140E6D: to=<AAAA3gcBGAcA@appmaildev.com>, relay=mail.appmaildev.com(69.89.227.121):25, delay=2, delays=0.82/0/0.86/0.31, dsn=2.6.0, status=sent (250 2.6.0  <c3d209ac8e494f3eb51adfba4c5f5bec@internal*****.de> Queued mail for delivery)

Although the message gets out your server is (of course) added to postgreys geylist so your reply doesn't get through:


Jan 24 13:12:43 v3-1090 postfix/smtpd(20468): connect from mail.emailarchitect.net(69.89.227.124)
Jan 24 13:12:45 v3-1090 postgrey(8687): action=greylist, reason=new, client_name=mail.emailarchitect.net, client_address=69.89.227.124, sender=auth-report@appmaildev.com, recipient=andromeda@wurst****.de
Jan 24 13:12:45 v3-1090 postfix/smtpd(20468): NOQUEUE: reject: RCPT from mail.emailarchitect.net(69.89.227.124): 450 4.2.0 <andromeda@wurst****.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/wurst****.de.html; from=<auth-report@appmaildev.com> to=<andromeda@wurst****.de> proto=ESMTP helo=<mail.appmaildev.com>
Jan 24 13:12:45 v3-1090 postfix/smtpd(20468): disconnect from mail.emailarchitect.net(69.89.227.124)

I'm trying to temporary disable greylisting on my side, but you should consider changing to a valid certificate soon.

Cheers
Dachande

Edited by user 11 years ago | Reason: Not specified

ivan
100% (Exalted)
Administration Topic Starter

11 years ago

#3

Thank your valuable comments, we will consider to get a certificate for SMTP service.

flajzi
51.5% (Neutral)
Newbie

7 years ago

#4

Hello,
it seems your DMARC parser in DKIM test cannot correctly process parentheses (or it doesn't ignore all characters after e-mail) in From: field. When my Postfix server sends an e-mail with header "From: user@company.com (Root User)" instead of "From: Root User , your DMARC test script shows this:

_dmarc.company.com (Root User): Non-Record
Received-SPF: pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4
Authentication-Results: appmaildev.com;
dkim=pass header.d=mail.company.com;
spf=pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4;
dmarc=permerror (adkim=r aspf=r p=none) header.from=company.com (Root User);

Edited by user 7 years ago | Reason: Not specified

+1

ivan
100% (Exalted)
Administration Topic Starter

7 years ago

#5

Hello,
it seems your DMARC parser in DKIM test cannot correctly process parentheses (or it doesn't ignore all characters after e-mail) in From: field. When my Postfix server sends an e-mail with header "From: user@company.com (Root User)" instead of "From: Root User , your DMARC test script shows this:

_dmarc.company.com (Root User): Non-Record
Received-SPF: pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4
Authentication-Results: appmaildev.com;
dkim=pass header.d=mail.company.com;
spf=pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4;
dmarc=permerror (adkim=r aspf=r p=none) header.from=company.com (Root User);

Originally Posted by: flajzi

yes, it is a bug to parse email address with comments. we will fix it at next version (in one week).

ivan
100% (Exalted)
Administration Topic Starter

7 years ago

#6

Hello,
it seems your DMARC parser in DKIM test cannot correctly process parentheses (or it doesn't ignore all characters after e-mail) in From: field. When my Postfix server sends an e-mail with header "From: user@company.com (Root User)" instead of "From: Root User , your DMARC test script shows this:

_dmarc.company.com (Root User): Non-Record
Received-SPF: pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4
Authentication-Results: appmaildev.com;
dkim=pass header.d=mail.company.com;
spf=pass (appmaildev.com: domain of user@company.com designates 15.9.17.4 as permitted sender) client-ip=15.9.17.4;
dmarc=permerror (adkim=r aspf=r p=none) header.from=company.com (Root User);

Originally Posted by: flajzi

Hi, the issue about email address with comment part has been fixed, you can try it again, thank you very much.

+1

flajzi
51.5% (Neutral)
Newbie

7 years ago

#7

Hi, the issue about email address with comment part has been fixed, you can try it again, thank you very much.

Originally Posted by: ivan

It works now perfectly. Thank you very much!

petyy
50.75% (Neutral)
Newbie

6 years ago

#8

Hello. It looks like your parser is case insensitive for DKIM tags. I found out that TXT record with P= instead of p= passes as correct, which by RFC shouldn't be ok... Can you fix that, please? 🙂

ivan
100% (Exalted)
Administration Topic Starter

6 years ago

#9

Hello. It looks like your parser is case insensitive for DKIM tags. I found out that TXT record with P= instead of p= passes as correct, which by RFC shouldn't be ok... Can you fix that, please? :)

Originally Posted by: petyy

From DKIM RFC:

Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity.

You're right, we used case-insensitive comparison for tags in public key. We will fix it at next release.

psychonaut
54.5% (Neutral)
Newbie

5 years ago

#10

hi hope you are well.

i dont think your tool is dealing with subdomains properly - when i analyse my header i find that dmarc passes, but when i send a test email to you your tool says that there is no dmarc record for the domain.

the dmarc record exists on the domain, and i am sending out on a subdomain of it.

as far as i am aware, if there is no explicit dmarc record for a subdomain, it looks to the ultimate parent domain.

so, i.e.
i am sending out as something@x.y.z.domain.tld
and the dmarc record exists on domain.tld

the tool should, once it finds no dmarc record on x.y.z.domain.tld go and look at the dmarc record for domain.tld but i dont think it is doing this.

i can provide headers and the response from the tool if you like but i dont want to post them publicly

ivan
100% (Exalted)
Administration Topic Starter

5 years ago

#11

hi hope you are well.

i dont think your tool is dealing with subdomains properly - when i analyse my header i find that dmarc passes, but when i send a test email to you your tool says that there is no dmarc record for the domain.

the dmarc record exists on the domain, and i am sending out on a subdomain of it.

as far as i am aware, if there is no explicit dmarc record for a subdomain, it looks to the ultimate parent domain.

so, i.e.
i am sending out as something@x.y.z.domain.tld
and the dmarc record exists on domain.tld

the tool should, once it finds no dmarc record on x.y.z.domain.tld go and look at the dmarc record for domain.tld but i dont think it is doing this.

i can provide headers and the response from the tool if you like but i dont want to post them publicly

Originally Posted by: psychonaut

thank you very much, we will try to improve it at next version.

psychonaut
54.5% (Neutral)
Newbie

5 years ago

#12

can you confirm if i am correct that the tool does not work properly in the case of subdomains please? because if it does work properly then i need to find out what the problem is with my email system...

ivan
100% (Exalted)
Administration Topic Starter

5 years ago

#13

can you confirm if i am correct that the tool does not work properly in the case of subdomains please? because if it does work properly then i need to find out what the problem is with my email system...

Originally Posted by: psychonaut

From DMARC rfc, our tool doesn't query Organizational Domain while sub domain policy is empty, that is our tool bug.


Quote from:  RFC 7489                          DMARC                       March 2015

6.6.3.  Policy Discovery

   As stated above, the DMARC mechanism uses DNS TXT records to
   advertise policy.  Policy discovery is accomplished via a method
   similar to the method used for SPF records.  This method, and the
   important differences between DMARC and SPF mechanisms, are discussed
   below.

   To balance the conflicting requirements of supporting wildcarding,
   allowing subdomain policy overrides, and limiting DNS query load, the
   following DNS lookup scheme is employed:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

   2.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.

   4.  Records that do not start with a "v=" tag that identifies the
       current version of DMARC are discarded.

   5.  If the remaining set contains multiple records or no records,
       policy discovery terminates and DMARC processing is not applied
       to this message.

   6.  If a retrieved policy record does not contain a valid "p" tag, or
       contains an "sp" tag that is not valid, then:

psychonaut
54.5% (Neutral)
Newbie

5 years ago

#14

phew! thats great, that means the problem is for you and not for me!

ok, let me know when you fix it please.

ivan
100% (Exalted)
Administration Topic Starter

5 years ago

#15

phew! thats great, that means the problem is for you and not for me!

ok, let me know when you fix it please.

Originally Posted by: psychonaut

Hi, we have fixed this problem, you can try it now.

psychonaut
54.5% (Neutral)
Newbie

5 years ago

#16

doesn't work i'm afraid

ivan
100% (Exalted)
Administration Topic Starter

5 years ago

#17

doesn't work i'm afraid

Originally Posted by: psychonaut

could you download and send the report to support@emailarchitect.net so that I can have a check?

psychonaut
54.5% (Neutral)
Newbie

5 years ago

#18

done, email sent. i think you may have fixed the issue in the meantime though!

pabujgl
50.75% (Neutral)
Newbie

a year ago

#19

Hi there!

Is there any way to give the correct ip address of the source ip into the copied eml file? Or could you maybe add an ip field where we could enter the source ip address. At the moment just every mail i copy tells me, that SPF is wrong, because he takes 127.0.0.2 as source ip.

Thank you very much,

Patrick

ivan
100% (Exalted)
Administration Topic Starter

11 months ago

#20

Hi there!

Is there any way to give the correct ip address of the source ip into the copied eml file? Or could you maybe add an ip field where we could enter the source ip address. At the moment just every mail i copy tells me, that SPF is wrong, because he takes 127.0.0.2 as source ip.

Thank you very much,

Patrick

Originally Posted by: pabujgl

The source IP is parsed from the received header:
for example:


Received: from mta195c.pmx1.senderdomain.com (142.54.247.195) by
 CH3PEPF00000011.mail.protection.outlook.com (10.167.244.116) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.8005.1 via Frontend Transport; Wed, 18 Sep 2024 01:28:04 +0000

then 142.54.247.195 is the source address, so you should add such received header to indicate the correct source IP address if you test the email with upload.

Important Information:

EXPLORE TUTORIALS

Send Email

Read and Parse Email

DKIM Solution