Subject: | test Fri, 28 Feb 2025 06:37:27 -0800 | |
From: | steve@wordtothewise.com | |
Yahoo / Google | Doesn't comply with Yahoo / Google requirements. 7 / 9 | |
Authentication | SPF Aligned DKIM Aligned DMARC pass p=none | |
IPv6 | Fully IPv6 Ready | |
Message received | Feb. 28, 2025, 2:37 p.m. | |
HELO | mail.turscar.ie | |
Peer IP | 2a00:1098:88:f6::1 (mail.turscar.ie. rDNS) | |
Email size | 1.0 KiB |
pass | SPF Passes Aligned | ||
| Result | pass | |
| DNS operations | 1 | |
| Void DNS operations | 0 | |
| Hostname checked | wordtothewise.com | |
| Peer IP address | 2a00:1098:88:f6::1 | |
| Aligned |
SMTP session from 2a00:1098:88:f6::1 (mail.turscar.ie. FCrDNS)
connection from [2a00:1098:88:f6::1]:48280 | |
220 aboutmy.email | |
EHLO mail.turscar.ie | |
250-aboutmy.email | |
250-STARTTLS | |
250-PIPELINING | |
250-SIZE 10240000 | |
250-ENHANCEDSTATUSCODES | |
250 DSN | |
STARTTLS | |
220 2.0.0 Ready to start TLS | |
TLS 1.3 handshake negotiated | |
EHLO mail.turscar.ie | |
250-aboutmy.email | |
250-PIPELINING | |
250-SIZE 10240000 | |
250-ENHANCEDSTATUSCODES | |
250 DSN | |
MAIL FROM:<steve@wordtothewise.com> | |
250 2.1.0 Ok | |
RCPT TO:<wise.garden.drink@aboutmy.email> ORCPT=rfc822;wise.garden.drink@aboutmy.email | |
250 2.1.0 Ok | |
DATA | |
354 Go ahead | |
(email payload) |
Dkim-Signature: | v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=blueberry; t=1740753450; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; h=Date:To:From:Subject:From:Subject:Date:To:Reply-To:Cc; b=bnhAoG1EFS/caezYFj4QZgZoNRFHRFlgxcNLEqrmgSBWUjBpnw49luaKznabqnbgU +hRlWVkq4SIKGG70P8f9+wTKjbwg4wNb2Sfa6161VELi3AnJaSpvqtOkq5eM9yNHxh aRf753X0QQMni8A9Pwv0vnhCs8h7bQRLD7v6CTXJ9XzH3iItAOwIZMUmxywAboUxvl ZPjUBtqhkJyXmeFqnhAJXvaWhs1C+7d+0EOidXlrvY7sl9ykiW+4i+fbb+zsDpnD+f s9cjJpLOC3oZKgSnwcncQlcXuCilHulG2onjXUjhxOQeQmEia2kXpQ3UGYIbuzT20f RzIiTUQy0FXvw== | |
Received: | from pazu.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by mail.turscar.ie (Postfix) with ESMTPSA id CAD3995B for <wise.garden.drink@aboutmy.email>; Fri, 28 Feb 2025 14:37:29 +0000 (UTC) | |
Date: | Fri, 28 Feb 2025 06:37:27 -0800 | |
To: | wise.garden.drink@aboutmy.email | |
From: | steve@wordtothewise.com | |
Subject: | test Fri, 28 Feb 2025 06:37:27 -0800 | |
X-Mailer: | swaks v20130209.0 jetmore.org/john/code/swaks/ |
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=blueberry; t=1740753450; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; h=Date:To:From:Subject:From:Subject:Date:To:Reply-To:Cc; b=bnhAoG1EFS/caezYFj4QZgZoNRFHRFlgxcNLEqrmgSBWUjBpnw49luaKznabqnbgU +hRlWVkq4SIKGG70P8f9+wTKjbwg4wNb2Sfa6161VELi3AnJaSpvqtOkq5eM9yNHxh aRf753X0QQMni8A9Pwv0vnhCs8h7bQRLD7v6CTXJ9XzH3iItAOwIZMUmxywAboUxvl ZPjUBtqhkJyXmeFqnhAJXvaWhs1C+7d+0EOidXlrvY7sl9ykiW+4i+fbb+zsDpnD+f s9cjJpLOC3oZKgSnwcncQlcXuCilHulG2onjXUjhxOQeQmEia2kXpQ3UGYIbuzT20f RzIiTUQy0FXvw== Received: from pazu.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by mail.turscar.ie (Postfix) with ESMTPSA id CAD3995B for <wise.garden.drink@aboutmy.email>; Fri, 28 Feb 2025 14:37:29 +0000 (UTC) Date: Fri, 28 Feb 2025 06:37:27 -0800 To: wise.garden.drink@aboutmy.email From: steve@wordtothewise.com Subject: test Fri, 28 Feb 2025 06:37:27 -0800 X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
Payload size: | 1 KB (1,040 bytes) |
Lines: | 22 |
Longest line: | Line 11, 82 characters |
Non-ascii characters: | none |
Bare line feeds: | none |
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=blueberry; t=1740753450; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=; h=Date:To:From:Subject:From:Subject:Date:To:Reply-To:Cc; b=bnhAoG1EFS/caezYFj4QZgZoNRFHRFlgxcNLEqrmgSBWUjBpnw49luaKznabqnbgU +hRlWVkq4SIKGG70P8f9+wTKjbwg4wNb2Sfa6161VELi3AnJaSpvqtOkq5eM9yNHxh aRf753X0QQMni8A9Pwv0vnhCs8h7bQRLD7v6CTXJ9XzH3iItAOwIZMUmxywAboUxvl ZPjUBtqhkJyXmeFqnhAJXvaWhs1C+7d+0EOidXlrvY7sl9ykiW+4i+fbb+zsDpnD+f s9cjJpLOC3oZKgSnwcncQlcXuCilHulG2onjXUjhxOQeQmEia2kXpQ3UGYIbuzT20f RzIiTUQy0FXvw== Received: from pazu.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by mail.turscar.ie (Postfix) with ESMTPSA id CAD3995B for <wise.garden.drink@aboutmy.email>; Fri, 28 Feb 2025 14:37:29 +0000 (UTC) Date: Fri, 28 Feb 2025 06:37:27 -0800 To: wise.garden.drink@aboutmy.email From: steve@wordtothewise.com Subject: test Fri, 28 Feb 2025 06:37:27 -0800 X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/ This is a test mailing
Answers | |||
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.f.0.0.8.8.0.0.8.9.0.1.0.0.a.2.ip6.arpa. | 59m59s | PTR | mail.turscar.ie. |
Answers | |||
mail.turscar.ie. | 1h0m0s | AAAA | 2a00:1098:88:f6::1 |
Answers | |||
wordtothewise.com. | 1h0m0s | TXT | "google-site-verification=iYbVC0LLlEnUaQLNNzEH3eHygNlWtZTF8Y-kiSWrIIA" |
wordtothewise.com. | 1h0m0s | TXT | "v=spf1 ip4:104.225.223.158 ip4:104.225.223.157 ip4:216.189.157.158 ip4:185.97.236.152 ip4:46.235.231.167 ip6:2a00:1098:88:f6::1 ~all" |
wordtothewise.com. | 1h0m0s | TXT | "yahoo-verification-key=JuG1lb9gIHEdP4SkfzQFL6UakvdDzApFleX2+PH7Nmg=" |
wordtothewise.com. | 1h0m0s | TXT | "MS=74E5371B4D2754BA59B25B630DDCD51A9CEE1A17" |
Answers | |||
blueberry._domainkey.wordtothewise.com. | 1h0m0s | TXT | "v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0FOof0FrJBTMxNm/3KbLSnUgBwX5jVkRILFEJJltBbaH0ZqduoUau/NcjioYgDSO8ktF6f4YnUem7VjARTzkl7mnQA9qlhF0Ix0W72oL5cDd6EptuoNn88ws9nBRvDBkeSjFNo/ftvrr6wEMet93EC0mxXKZXT9jgPTAii+cXl1Jg7QkO64DySFUDAodmaBMN9mVtr8P6drO0P" "sG8RxH9KfvEtLS4L1a42TB7CtydMeIGQJKW51C55cIRhLVXzZ8emdTpZ067tdYNdeHFX7WsSEa5XBIJoDE8LI8RHrYSIdUbtGqkWncy9U0yYjVPJj369Q7yBgWZiwGrjbUQBr3XQIDAQAB" |
Answers | |||
_dmarc.wordtothewise.com. | 1h0m0s | TXT | "v=DMARC1; p=none; rua=mailto:re+a3gusz21yva@dmarc.postmarkapp.com" |
Answers | |||
dmarc.postmarkapp.com. | 1h0m0s | MX | 10 inbound.postmarkapp.com. |
Answers | |||
wordtothewise.com._report._dmarc.dmarc.postmarkapp.com. | 1h0m0s | TXT | "v=DMARC1;" |
NXDOMAIN | |||
Answers | |||
(no answers) | |||
Authority | |||
wordtothewise.com. | 59m59s | SOA | udns1.ultradns.net. . 2015102948 10800 3600 2592000 86400 |
NXDOMAIN | |||
Answers | |||
(no answers) | |||
Authority | |||
wordtothewise.com. | 59m59s | SOA | udns1.ultradns.net. . 2015102948 10800 3600 2592000 86400 |
Hostname | Links | Images | Weight
|
Bloat
|
Aligned
|
IPv6
|
---|
| |
| |
| |
| missing |
|
Practices that large mailbox providers would like to see in bulk mail streams.
SPF | |||
DKIM | |||
|
Reverse DNS | ||
|
Opportunistic TLS | ||
|
Allowed Domain | ||
|
DMARC | ||
|
Aligned Authentication | ||
|
RFC 8058 one click Unsubscribe | ||
|
In-body unsubscribe |
Session encryption | TLS 1.3 |
Cipher suite | TLS_AES_128_GCM_SHA256 |
This message has no HTML parts.
AboutMy.email is a tool to analyze an email for technical good practice. It's currently in an alpha release state, so expect to see some bugs. If you find any feel free to file a bug or mention it on Slack.
An email sender can demonstrate to a recipient that they really did send it in a variety of ways, including SPF, DKIM and DMARC. These are jointly described as email authentication.
SPF queries DNS to check whether an IP address is authorized to send email that uses a particular return path (or HELO).
It can return a variety of possible statuses, but for our purposes anything that isn't "pass" is a fail.
We only use the return-path / 821.From to check SPF, we don't check the HELO value. This isn't exactly how SPF is specified, but gives far more useful results when diagnosing authentication issues.
Querying SPF can involve follow pointers to other records, and from there to other records. The SPF standards limit the number of DNS related operations to 10, though enforcement of this by mailbox providers varies.
A void operation is a DNS query for SPF that returns no results. These are a sign of misconfiguration and if there are more than two the SPF check will fail.
DKIM authenticates an email by cryptographically signing the
email and storing the result of that signature in an email
header - Dkim-Signature:
An email receiver can retrieve the sender's public key from DNS and use that to confirm the signature is valid, and so that the mail was sent or authorized by the domain in the signature.
Despite being described as authentication, DMARC doesn't really authenticate the sender of an email. Rather it's a way for the sender to assert that they only ever send email that's authenticated using SPF or DKIM, so if you receive email "from" them, using their domain in the From: header, you should treat it with suspicion.
The size of the email as transmitted. This includes the headers, plain text and html parts, attachments and any encoding overhead.
The total size of the external images referenced by the email.
The bigger this is, the longer it will take to display the
email. This is a minimum - it only counts images referenced
directly in an <img>
tag, not srcset or css referenced images.
If you're serving oversized images intentionally, e.g. in the hope that they'll display better on hi-dpi displays that's fine. This is more to catch unintentional resizing.
An email will usually specify the size of an image in the
<img>
tag that references it. If the actual image fetched from
the remote server is a different size the mail client will
scale it up or down.
If the image is scaled down by the client that means the server is sending a larger image than the client needs. The bloat is the number of bytes that could be saved by serving a file the same size as the mail client expects.
Alignment is a term that comes from DMARC.
Loosely it means that two hostnames are in the same "domain", e.g. www.example.com and mail.example.com are aligned because they're both in the domain example.com.
More technically it means that the two hostnames share the same "organizational domain". That's usually the same thing as your intuitive idea of what a domain is, but it's a well-defined term. Currently, an organizational domain is defined by the Public Suffix List.
Generally when we use the term "aligned" this is what we mean, but this is what DMARC refers to as "relaxed alignment". The other type is "strict alignment", which requires the two hostname be identical.
If we describe just one hostname as "aligned" we mean that it's aligned to the domain of the email address in the From: header.
IPv6 is the "new" type of IP address that was standardised about 20 years ago, replacing the older IPv4 format.
IPv6 addresses look like 2602:ff16:9:0:1:17b:0:1::
, while
IPv4 addresses look more like 89.233.107.76
.
There's a shortage of IPv4 addresses - we've run out of newly minted IPv4 addresses completely, and are now just trading them around.
While it's unlikely there'll be any IPv6-only email servers for a long time, sending mail via IPv6 rather than IPv4 where possible can save scarce IPv4 resources (and might deliver with less delay or throttling in some cases).
IPv6-only clients are more likely to happen, as are IPv6 clients who only have access to IPv4 content via flaky, overloaded carrier grade NAT devices. Providing external content, such as images and landing pages, via IPv6 may make for a better, faster experience for those clients.
The List-Unsubscribe header, defined in RFC 2369, contains one or more URLs that a mail client can use to request a recipient be unsubscribed.
Typically, it will contain mailto:
or https
URLs (http
URLs may still work, but are obsolete and should be converted
to https
).
A mailto:
URL allows a mail client to request unsubscription
non-interactively, without the user needing to take any
further action, by sending an email to the given address.
An https:
URL allows a mail client to open a browser for
the user to visit the given URL. From that page they're
expected to be able to unsubscribe from all email and,
optionally, to use a subscription center to unsubscribe
from subsets of the senders email.
The https:
URL is also used as part of the protocol for
"one-click" unsubscribes.
The List-Unsubscribe-Post header, define in RFC 8058, is used to enable non-interactive, "one-click", unsubscription.
It contains a fixed value, List-Unsubscribe=One-Click
, and
signals that a https:
URL provided in the
List-Unsubscribe header can be used
non-interactively via a http POST to request unsubscription
without any additional user interaction required.
Mailbox providers want to be able to help their users manage the mailing lists they subscribe to, e.g. Yahoo's Subscription Hub.
They also want to be able to offer user the option to unsubscribe from email they don't want, for example as prompt to unsubscribe as an alternative to blocking a sender in response to the user marking an email as spam.
To provide this user interface the mailbox provider needs to be able to manage unsubscription on the users behalf, often described as non-interactive, in-app or one-click unsubscription.
These can be provided in two ways. The older, deprecated,
approach is a mailto:
URL in a
List-Unsubscribe header which
will trigger an unsubscribe in response to an email to
a special address. This is asynchronous and doesn't provide
any feedback to the mailbox provider, so isn't a good match
to an interactive, real-time unsubscription interface. The
newer, strongly preferred, approach is the
List-Unsubscribe-Post header,
which provides a web API for unsubscription.
Users expect a link in the footer of an email they can click on to go to a webpage to unsubscribe from this sender, or manage their subscriptions. This is the usual way to comply with legal requirements around unsubscription. These requirements are usually not satisfied by List-Unsubscribe headers, so you need this link in addition to those, not instead of.
The expected behaviour for this web page is identical to the expected behaviour of that provided by the List-Unsubscribe header, so they'll often be identical. (Adding a parameter to distinguish the two is useful if you want to be able to report on how a user unsubscribes).
The List-ID header, defined in RFC 2919, provides a way for mail clients to identify a particular mail stream.
It typically contains two parts - an optional human-readable description and a machine-readable part that looks something like a hostname.
The machine-readable part is hierarchical, which allows a mail client to group related mailing lists together easily.
The human-readable part is optional, but if it's missing the recipient may see the more confusing machine-readable description in their UI, for instance when managing subscriptions.
It's not currently required for delivery to Yahoo or Gmail, but you should strongly consider adding it soon.
Reverse DNS uses the domain name system to find the hostname associated with an IP address. This is called reverse DNS as it's the reverse of the more common case of finding the IP address associated with a hostname.
Reverse DNS is something that's configured by the owner of an IP address, which means they can claim to be any hostname they want. Because of this, most uses of reverse DNS require Forward-confirmed reverse DNS (aka FCrDNS, full-circle reverse dns, or round-trip reverse dns). This allows someone to be sure that the IP address and hostname are controlled by the same entity.
Reverse DNS is particularly important for IP addresses that are sending email, as it's the lowest bar for demonstrating that the IP address belongs to a properly configured server rather than an infected consumer machine.
It's polite, and demonstrates a level of operational competence, to have FCrDNS on any IP addresses you're providing public services from.
SMTP doesn't require TLS encryption, but supports upgrading an SMTP connection to one encrypted by TLS using the STARTTLS command. Offering, but not requiring, TLS like this is called opportunistic TLS.
We think that any sender of email should ideally use STARTTLS if the receiving server offers it.
Hosting providers often mechanically set reverse DNS across
all their IP space, so it will look more like 89-233-107-76.static.example.net
than mail.example.com
.
This is known as generic reverse DNS, and is often a sign that the server hasn't been properly set up and maybe shouldn't be trusted as a source of email.
The first command an email client sends to a server is EHLO (or HELO) with a parameter that should be the hostname of the sending server.
While this isn't used for authentication (other than some corners of SPF usage) some malware and some snowshoe spammers have distinctive patterns of HELO.
Yahoo and Google have announced what behaviour they expect to see from well-behaved bulk senders.
If anything on your Good Practice page is red, you're probably not complying with their requirements, and your delivery is likely to suffer.
When you visit the home page you're given an email address. That address only exists while the page is open - if you close or refresh the page that address is deleted and will bounce.
Once the email has been delivered we process it and then redirect you to the report page. The URL of that report page is a permanent link - you can bookmark it, share it with other folks and so on. That permalink will always remain available for at least seven days (right now it'll likely stay around forever, at least until we run short of storage).
No. The content is rendered by your browser, not by any sort of device emulator. The size selector lets you set the viewport size by adjusting the size of the iframe it's rendered in, but that's all.
It's in this json file, initially imported from the excellent viewportsizer.com.
And the cobbler's children go barefoot.
I generally try and set up my services to follow good practices, but things like reverse DNS are far lower down the list than security and data integrity.
And sometimes I intentionally break requirements (some of my domains have no SPF, others have DMARC rua records without external verification, ...) just to see what happens.
If you want to integrate AboutMy.email with your system via API, or want to talk about a white-label version, contact us.
If you just want to point your customers at our public instance, feel free.
As well as AboutMy.email we have a bunch of other tools that email folk might find useful.
aka emailstuff.org
This is very useful for testing SMTP implementations and bounce handling. It lets you send an email and control exactly how it will be rejected - what rejection message, where in the SMTP transaction and so on.
Help for people deploying DKIM authentication.
I should document this better, but there's a lot of email related tools on github/wttw
AboutMy.email lets you send an email to a unique address, then it will tell you many things about it.
It's still very much in an alpha release state, so expect to see some bugs. If you find any feel free to file a bug or mention it on Slack.
We are Word to the Wise, an Email consulting company based in Dublin, Ireland.
Word to the Wise was founded by Steve & Laura Atkins in 2001, in the heart of Silicon Valley.
We were one of the first companies to offer email senders strategic advice on email delivery and program management, and continues to be at the forefront of the industry helping companies develop and manage sustainable email programs.
Two decades later, we’re based in Dublin, Ireland and still offering a boutique, hands-on approach to solving email problems and building sustainable email programmes, both as Word to the Wise and under our Irish name, Turscar.
We are a trusted advisor not only to email senders of all sizes, but also to many of the email and internet service providers who support those companies. When in-house experts need additional advice and support, we can provide both short-term and long-term assistance in navigating those challenges.
We do. Check out our FAQ.
You're welcome to use our public instance of AboutMy.email as part of your work, or to point your customers at it.
If you'd like to use it via API, integrate it with your platform or talk about a white-label version, email us.
If you'd like a quote for technical consulting, development or email forensics, email us.
AboutMy.email lets you send mail to a unique address, then tells you lots of things about it. It's mostly useful if you're working with email authentication, delivery or design.
Check out our FAQ.
If you'd like a quote for technical consulting, development or email forensics, email us.
The friendly folks on the EmailGeeks Slack might be prepared to help. But take a look at this first.
This is all very much in an alpha release state, so there will be bugs.
Feel free to report bugs or ask for new features via our tracker. For bugs, include the URL of a results page.
We don't promise to do anything other than read these.
The server running is currently version v0.9.23-1-g2427f6f-dev-rev-2427f6f-2024-07-27-08:18.
The results you're looking at (6f3e8d8) were generated by server version v0.9.23-1-g2427f6f-dev-rev-2427f6f-2024-07-27-08:18.
Copyright © Turscar Ltd, 2023. All Rights Reserved.
Most icons are © Fonticons, Inc, used under license.
Emails you share with this site will be used to provide you with the data about them you've requested. That data, including the entire content of the email, is made available without any authentication needed at a semi-private URL.
We don't currently plan on using any of that data for anything other than ensuring smooth running of the site.
Contact us if you have any questions.
Cookies are used to record language preference and history of emails analyzed.
History tracking is enabled.
Can mail be delivered to an IPv6-only recipient?
Yes. This mail was sent from 2a00:1098:88:f6::1.
Can an IPv6-only client fetch remote content?
Hostname | IPv6
|
---|
Feb. 28, 2025, 2:37 p.m. | test Fri, 28 Feb 2025 06:37:27 -0800 |
History tracking is enabled.