I hate

Same way, a link unique to the recipient. Not sure how you get around that particular issue, but thankfully that's not my problem as I'm not a marketer or deliverability expert (yet). But it's an interesting question that I now want to know the answer to.

Seems to be a few options;

If the "Unsubscribe" page is requested via HTTP GET, it renders a simple confirmation form and a bit of JS that submits the form on page load
If the "Unsubscribe" page is requested via HTTP POST then we unsubscribe the user

Or, add a timer so that any immediate clicks (within 5 minutes of the send, say) return a captcha or something.

Probably more elegant ways. But it will be up to the big marketing email providers to work that out.

As a marketer, some of the incoming changes are a little bit worrying but luckily most of my clients have the same opinion as me - if someone doesn’t really want the emails, we don’t want them on the list. Skews the data, costs money, everyone loses.

Are you across the other changes?

There's undoubtedly a load of stuff I'm not aware of (I'm content/strategy rather than mechanics), but I know about the DMARC and spam stuff?

DMARC

That's my job essentially, send me a message if you need anything.

Oh amazing - I'm yet to put anybody through the DNS stuff, so may well send a PM your way! thanks

Toothache.

Ouch. You have everyone’s sympathy, I’m sure!

https://www.youtube.com/watch?v=z-8JELUcjMM

... Models

See what I did there?

Let's try...

How does an SPF record of 299 characters pass validation? (255 limit per TXT entry right?)

It's not split.

domain?

It is very likely in multiple strings

I can definitely sympathise.

I had a root canal on Monday that was the end of some dental problems that started back in November. Only a couple of days of pain in that time but my was that some pain.

It's a secret.

But I've just looked at the DNS and it's definitely a single TXT record of 299 chars on @ and in fact has two other SPF TXT entries for "mail" and "ir" whatever the fuck that is (AWS SES).

SES uses a subdomain for the Mail From (to keep bounce processing and still achieve SPF alignment for DMARC), so that's why you have SPF records there (Header From of the messages will be the @, Mail From/Envelope Sender is the subdomain).

I'd need to see the domain to comment further.

It may look like a single string in your platform but the public record will (should) be split.

I dunno, MX Toolbox shows it as one and validates it ok. Someone must've found a loophole :)

MX Toolbox

There's your problem. If you're running an SPF check, it will be concatenating the strings back into a single record. DIG the TXT record and you'll see the split/quotes/spaces.

ssa-test.com. 3600 IN TXT "v=spf1 ip4:1.2.3.1 ip4:1.2.3.2 ip4:1.2.3.3 ip4:1.2.3.4 ip4:1.2.3.5 ip4:1.2.3.6 ip4:1.2.3.7 ip4:1.2.3.8 ip4:1.2.3.9 ip4:2.2.3.1 ip4:2.2.3.2 ip4:2.2.3.3 ip4:2.2.3.4 ip4:2.2.3.5 ip4:2.2.3.6 ip4:2.2.3.7 ip4:2.2.3.8 ip4:2.2.3.9 ip4:3.2.3.1 ip4:3.2.3.2 ip4:3.2." "3.3 ip4:3.2.3.4 ip4:3.2.3.5 ip4:3.2.3.6 ip4:3.2.3.7 ip4:3.2.3.8 ip4:3.2.3.9 ~all"

1 Attachment

Yeah but I looked at the DNS and it's not split unless they also do some weird shit behind the scenes.

The output of dig on it is actually longer because it's stuck some quotes in places (maybe the magic split + concat?)

Yeah but I looked at the DNS and it's not split unless they also do some weird shit behind the scenes.

Godaddy shows my example above as a single string. Then does it's weird shit to make it work in DNS.

Multiple strings enclosed in quotes and separated by a space. The verifier will remove the " " and smash it all back together again when it realises it is an SPF record. So in your case, the second string is ip4:xxx.xxx.xx.192/27 ip4:xxx.xx.xxx.36 ~all

If it is a domain you give a shit about, put your explicit ip4's ahead of your includes. Currently, if any of those IPs want to pass, the verifier needs to complete at least 7 other lookups first. 7 is within the acceptable limit of 10, but a free improvement and general rule of thumb would be to put the IPs first.

Going over 255 characters is less of an issue today, but some people are adamant they need to stay under it. The look up limit is more of a concern.

1 Attachment

You think the DNS provider is splitting it after entry and then everything else is smooshing it back together. That sounds way to organised to me but I guess it's possible.

Thanks for the performance tip.

That's exactly what's happening. Not all providers do, a lot will. See also 2048 bit DKIM Public Key records. They have to be TXT records but are always going to be >255 characters.

Makes sense. I'm used to DNS providers being shite so I didn't expect something actually useful to be happening.

Car tyre garages who struggle with the concept of staggered wheels