Yes, but you don't really do it as a background image, you can load it as an image and use your position:absolute and position it accordingly with left and top css properties on the image element. Then you can overlay a table to include text overlay or add and position additional images—such as a logo—that need to be overtop the background image. You want to make sure you exclude any regular images from outlook and include them as additional VML image elements otherwise Windows10 Mail won't render the images.
So basically save out your image at 50% quality and double the dimensions and then you can use cover for css friendly clients and use absolute dimensions to scale it correctly in Outlook and Windows10 Mail.
Here's an example of the code I've been using for a while and It has fairly robust support across clients.
<!--[if (mso)|(IE)]>
<table align="center" border="0" cellspacing="0" cellpadding="0"><tr><td align="center" valign="top" width="724"><tr><td style="height:400px">
<v:image xmlns:v="urn:schemas-microsoft-com:vml" id="theImage" style="behavior: url(#default#VML); display: inline-block; position: absolute; width: 724px; height: 400px; top: 0; left: 0; border: 0; z-index: 1;" src="hero.jpg" />
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="display: inline-block; position: absolute; width: 652px; height: 328px; top: 0; left: 36px; border: 0;z-index: 3;">
<v:fill opacity="0%" style="z-index: 4;"/>
<![endif]-->
<div class="hero">
<!--[if !mso]>-->
<table role="presentation" align="center" border="0" cellpadding="0" cellspacing="0">
<tr>
<td style="padding:0 36px">
<!--<![endif]-->
<h1>
Title Text Here
</h1>
<!--[if !mso]>-->
</td>
</tr>
</table>
<!--<![endif]-->
</div>
<!--[if (mso)|(IE)]>
</v:fill></v:rect>
</td></tr></table>
<![endif]-->
and here's the applicable css
.hero {
width:100%;
min-width:724px;
min-height:400px;
background:0 0/cover;
background-image:url(hero.jpg);
background-size:cover;
background-repeat:no-repeat;
background-position:center;
margin:0;}
.hero table {
width:724px;
}
I'm not sure that will get you very far.
We had a client that was inquiring about it due to a cold call their IT team got from Agari—it was part of their pitch. After looking into it this appears to be more of a marketing avenue for Agari and ValiMail more than anything else. It's a standard they've created and the only place it works currently is inside of Yahoo! web mail and what happens to it with the Yahoo! Aol. merge of properties is unknown.
It is a great idea on its surface but as long as it's a proposal that isn't supported by or created with input from the major players it's likely not going anywhere as it would require MUA and MTA code changes to insert and access the new headers and perform the verification checks. Further their final plan for it would move away from DNS TXT records and involve a certificate granting authority that would make things even more complicated.
I'm pretty much opposed to anything that acts as a secondary layer to standards when it comes to the web. All the stated goals of AMP can be achieved via normal HTML, CSS and JS if the true focus was on mobile speed. Most publishers sites are bloated due to including the numerous scripts that come along with their chosen advertising/tracking/analytical/social platforms. We all know the web has a definite over-eating problem–no non-app page can justify being 10s of MB in size–but is AMP really the solution?
If Google had let it be known that page load was going to be a major factor in their ranking formula publishers would be putting their sites on a diet real quick. Mostly, AMP has achieved a way for google to keep the end user in Googles eco-system and allows them to collect ever more data. In some ways it is good from the users perspective – even there it has it's issues – but is it good for the web as a whole? In the end I think AMP is doing more harm than good to both publisher and consumer.
AMP for email sounds of nothing more than a bad joke. EVERYTHING it achieves can already be done – if Google would update and standardize their CSS support across offerings – just like the web version of AMP. I see a couple big problems with it as well:
1) Most marketers won't be able to send AMP emails as it requires an additional MIME attachment to the email. Without incentives from Google or large demand from clients I don't see ESP's quickly rolling out this functionality.
2) An AMP email is going to increase the size of emails and the bandwidth required to work with them. While AMP for web greatly decreases the bandwidth required AMP for email will increase load times as it's adding in a completely separate attachment. Google's servers are likely only going to grab the AMP portion of an email to send to the user but every other mail client is going to download the text/plain, text/html and text/text-x-amphtml portions of the email before even getting to the render phase.
3) We all know how corporate/gov/educational networks can be overzealous with their spam and virus filtering and how slowly they are to update these installs. Given that AMP would be an unknown mime-type to the majority of these systems it could easily result in any email that contained an AMP attachment being quarantined erroneously.
Aside from the technical hurdles and foibles it introduces I think AMP for email would ultimately make all emails seem the same. Just like AMP for the web has made a large swath of the internet adhere to googles ideas for design. For all the issues the email world currently has creativity isn't one of them. We've all seen our fair share of horrible emails but I don't think AMP is the solution to making them better.
Ultimately I think AMP email is a solution looking for a problem. Personally I hope it goes the way of Grid View, a quiet uneventful death before full roll-out.
Just FYI, most attorneys we've dealt with on this have all interpreted CASL as requiring the checkbox/radio/toggle regardless of whether the purpose of the form is to solely sign up for email or whether the form's primary purpose is something else entirely. Obviously this isn't gospel and and one could probably find a legal opinion that differs.
I think the reasoning they have interpreted it this way is because without that indication of "Yes I want to receive emails" it could be argued that merely submitting the form wasn't consent as the language of the form or the submission button could be construed as being ambiguous. Personally coming from a government background I know that the more explicit in your explanation and forms you are the better...there's always someone out there that can find an argument for why something that seems simple and straightforward on its face is neither.
Having just finished some work for a Canadian company a couple months ago I can tell you that CASL is silent when it comes to whether something can be a required element of a form or not. As long as the consent checkbox/toggle/radio isn’t already in the affirmative state you should be good.
That said, if your company has in-house legal council — or a firm of record — it might be a good idea to get them to sign off on it. As an agency we know the specifics fairly well of the law but at the end of the day we aren’t attorneys. Anytime you’re dealing with legal requirements that have fairly steep penalties it’s always a good call to have an attorney look it over real quick.
I'm not as familiar with Android but I know on iOS you just have to register a custom URL scheme in your app. Then, say your custom URL scheme is marcepansapp, all you would need to do in your email is do a normal link and make the href="marcepansapp://[string]" where the string would tell your app what to do or load. You can get more information about custom schemes on the Apple Developer Connection site.
Once you have your custom URL scheme set up and deployed in your app you can then take a look at this thread on ways to show the custom URL scheme to iOS users and then show something else to everyone else.
https://litmus.com/community/discussions/6244-ios-specific-links
Switch your fill type to "tile" and that should solve your problem provided the image you're using is 600px wide. As far as I know there isn't an attribute in the vml markup to indicate whether a tiled fill should be repeated or not so if your image width is less than 600px it's going to get repeated. Any background image that is wider or taller than the defined rect size will just be cropped.
Jaina's correct - there's no email information that is going to be passed along to the web server unless it's in the URL.
You could track the forwarded email if it was forwarded via your ESP or your specific app/web page by appending the forwarded email address to the links in the forwarded email but if a user simple hit forward in their native email app there's no way to find out definitively who they forwarded that email to. You could potentially use tracking companies to match the user hitting your site to someone in their database but even then I wouldn't have enough confidence in that data to do something like pre-poulate fields or tag hits to specific users.